F5 CES 用融合的思想保护k8s出向流量安全

2022年07月14日 1896点热度 1人点赞 0条评论

在上一篇文章中，我们分析了为什么需要对k8s出向流量进行安全管控。并分析了6大类解决方案的特点。可以清晰的看出，将外部安全设施与k8s融合是有效实现出向流量精细化管控的方案。无论是安全管控的技术实现，还是让多团队协作来落地纵深防御的思想，方案都具备了良好的支持和覆盖。

在本篇文章中，我们将具体阐述F5 Container Egress Traffic（CES）方案的一些细节与使用场景。

CES可以理解为一种解决方案，它包含一个运行在k8s内的控制器，以及运行于k8s外部的F5 AFM（虚拟或硬件F5）:

CES控制：运行于k8s内的容器。该组件为控制面组件，负责将k8s内部署的出向策略转化为外部数据面组件上的配置。
F5 BIG-IP AFM: 运行于k8s外部的数据面组件。接受CES控制器下发的配置，并执行具体的访问控制规则，如访问控制列表、限流、流量编程等。
CNI: CNI属于用户环境本身的选择，并不包含在CES方案内。但不同的CNI会对CES方案的功能有不同的影响。使用kube-ovn CNI能够获得CES完整功能。

整体架构

在k8s的每个集群内可以运行一个或多个CES控制器，在集群外部可以为各个集群部署共用或独立的F5 AFM实例（虚拟或硬件F5）。用户通过在k8s集群内下发CRD资源实现对策略的部署，控制器自动化的发现策略的变化并将其部署到F5 AFM实例上。在网络上，pods主动出向流量以无SNAT的方式发往F5，技术上可通过CNI的能力，策略路由，overlay隧道等方法来打通和实现流量的控制。CES控制器程序开源在F5 Devcentral github上。

策略设计：

在上一篇文章中，我们多次分析了安全团队与开发团队以及平台团队的协作是实现可靠出向安全策略的重要前提。因此在F5 CES解决方案中，专门设计了三种不同的k8s资源（CRD）。这三个资源面向不同的团队角色，以下是具体的CRD描述与角色对应：

CRD名	Scope	描述	适配角色
ClusterEgressRule	Cluster global	该维度策略为集群的整体级别策略，用于控制集群通用的、整体性的访问控制。例如集群对企业NTP，DNS等基础公共服务的访问控制。该scope的策略应用到集群所有服务的出向访问控制。	集群管理员基础安全团队
NamespaceEgressRule	namespace	该维度策略对单个namespace或project生效。用于控制某些具体的NS或project内的所有服务对集群外服务访问。不同namespace或project内的策略彼此互不影响。*该功能需要CNI配合支持。	项目团队应用运维团队
ServiceEgressRule	k8s service	该维度策略控制某个具体k8s service所关联的相关endpoint容器对集群外部服务的访问。仅对具体的服务生效。	项目团队应用运维微服务owner

在实际工作中，负责企业整体安全的team可为各个集群设置基本的通用出向安全策略，比如统一容许所有pods访问企业内部特定服务，如NTP服务等。各个不同项目团队负责自身项目namespaces中需要的统一出向策略，例如在某个项目中涉及的应用均需访问的一个外部服务。在各应用项目中，负责某些具体微服务的小组则负责设定具体微服务单元需要的外部访问。通过这样层级化的设定，可以精细的设定从整体集群，到应用，到具体微服务单元的各维度策略。企业的安全团队在发现项目组或微服务小组开放了错误的出向策略时，可在全局维度下发禁止性策略来覆盖，这样可实现在审计或发现安全事件时进行临时性管控。