共计 4218 个字符，预计需要花费 11 分钟才能阅读完成。
编辑
作者：林静
职务：资深架构师
公司：F5
为何要进行 Egress 流量策略管控
2021 年 CNCF 考察显示，寰球将 kubernetes 用在生产环境的用户占比已达 59.77%，欧洲用户更是达到了 68.98%。用户正越来越多的将生产业务迁徙到 kubernetes 环境下。《Gartner 2021 Hype Cycle for Cloud Security》也显示了容器与 Kubernetes 平安已处在“slope of Enlightenment”阶段。
这阐明爱护 kubernetes 里的应用服务正变的越来越重要。当咱们去扫视运行在 kubernetes 中的大量微服务时，咱们能够看到微服务平安具备典型的微边界以及须要进行持续性安全工程的特点。
咱们须要以每个微服务为边界进行爱护，无论是其运行时，还是南北和货色流量。须要每个微服务单元在编码之初就开始着手平安思考，进行平安左移，平安的防护设施、办法、策略应与开发者和 kubernetes 平台运维者适配。
还须要有能力洞察所有的流量事件，采集所有运行时日志、事件等数据，通过持续性的安全工程系统对这些数据进行剖析，聚合出规定并反馈到平安的策略设定中。
kubernetes 里的微服务不会只在集群外部关闭运行，它须要拜访集群内部利用、数据库、第三方 API 服务、互联网服务等。出向流量里可能蕴含业务须要的内部拜访，开源组件更新的拜访，甚至可能是被入侵的利用向 C2 连贯的流量。因而，必须对 kubernetes 中的微服务被动外出流量进行管控，确保其平安合规。
在以云原生架构为核心技术驱动的数字化转型下，企业会大量采纳开源技术，而这可能是最容易引入平安危险的中央，无论是否有明确的开源准入机制，企业都应足够器重这些开源产品可能的被动外访服务，将其管控好，确保安全。
治理 kubernetes 中的出向流量策略，看似简略的需要，要想做好却并不是一件容易的事。本文将和您一起剖析 kubernetes 出向策略的挑战，并针对以后常见解决方案的优缺点进行剖析，思考企业应如何做好 kubernetes 出向流量策略管控。
存在的挑战
动静
从技术角度看，这是第一个存在的挑战。在 kubernetes 环境下，微服务单元的 pods 将是高度动静的、扩散的。IP、网段和物理地位将会随时发生变化。因而间接采纳 IP 等特色进行动态化策略设定将是一件不可能的事件。策略必须依赖于其它形象的利用标签、服务名或命名空间等进行，并能做到动静感知变动。
粒度
传统应用环境下，对一个利用出向流量策略的管控一般来说只须要对该利用所波及的大量部署进行策略设定即可。然而在微服务加容器化的环境下，一个利用可能会有许多的微服务组成，而一个微服务又蕴含许多 pods。不同的微服务单元会须要不同的出向策略规定，比方 payment 须要连贯第三方内部接口，而评论服务则不须要被动拜访第三方服务。
这意味着策略设定的粒度须要精密到每个微服务单元，并确保管控了所有相干的 pods。能够看出，策略管控粒度更细、工作量更大、复杂性更高。
协同
当咱们要为不同的微服务单元部署出向策略时候，谁应该为此负责，利用开发部门？利用部署与运维部门？kubernetes 的 platformOps 部门？或是安全部门？咱们以平安左移的思维去对待这件事时，显然利用部门应该思考他的微服务是否须要被动外访，须要拜访哪些内部服务。
然而，如果由利用开发人员负责，是不是平台或安全部门就能够放手不管？显然不是，利用开发人员最多是为其所负责的利用设定安全策略，与利用无关的全局性根底安全策略，如何疾速补救利用开发人员设定的谬误策略，这些仍然须要由其余团队来负责。
而要想开发部门可能践行平安左移的思维，那么 PlatformOps 或安全部门则必须提供敌对的工具并将安全策略的设定集成到 DevSecOps 的 pipeline 当中，如果工具或办法导致开发效率降落，开发人员将不乐意去应用。所以，这不是某一个部门的独立工作，须要多团队的合作来确保安全。
数据驱动
正如文章开始所述，平安是一个继续工程化的工作，意味着任何出向拜访行为与事件都应被记录到安全工程零碎中进行剖析，以确保足够的可见性和洞察。出向平安管控不仅仅是一个简略策略设定，需具备残缺日志、行为、事件输入的能力。
业界计划剖析
接下来，咱们来逐个剖析以后业界对于出向策略管控的解决方案，首先咱们将其分为 6 大类计划，而后再逐个剖析：
基于平台实现
kubernetes 自带的 Network policy，这是最容易想到的对于出向安全策略管控办法。它是 k8s 的本身能力，对于开发者或 PlatformOps 人员来说具备人造的亲和性，可能很好的适应平安左移的思维。但 Network policy 需 CNI 反对。其它一些毛病在于：
没有集群全局性的策略能力, 不同 namespace 下要保护独立的 policy
没有以 k8s svc 名称为条件的抉择能力（可改为选 pod 标签，但不灵便）无显式回绝能力，通过策略的隔离性特点，而后施加具体的白名单
规定无优先级概念
无明确的集群外访规定，内部指标服务只能依附宽泛的 ipblock
纯四层，无七层的控制能力
无策略执行调试能力
无策略执行日志
Networkpolicy 的“隔离性”特点使得保护工作变得及其麻烦，例如，自身只想管制其对互联网的拜访，但因为隔离性，就不得不额定保护该 pod 在集群内的所有出向（东西向）拜访
不能解决 k8s 与内部安全设备协同问题。试想一下，Network policy 做了规定管制后，那么内部的安全设备就能够为该集群关上一个默认通行的规定吗？Openshift，在 Egress 方面有四个个性与之无关，别离是规范的 Network Policy，Egress IP，Egress Router，Egress Firewall 以及 Egress NetworkPolicy。
Network Policy，当 Openshift 应用 OVN-Kubernetes 作为 CNI 时齐全反对，而传统的 Openshift SDN CNI 则仅是局部反对。与规范的 kubernetes 并无不同，其优缺点这里不再做额定剖析。EgressIP，是用来实现 Pods 流量来到集群时候应用确定性源 IP 的一种性能。当应用 Openshift SDN CNI 时，该性能将 Egress IP 利用到指定的 nodes 上作为 secondary IP，并用于 SNAT。当应用 OVN-kubernetes CNI 时候，则通过 OVS 为具体的 pods 执行 snat 规定。应用 EgressIP，自身并不是出向安全策略管控的间接办法，然而借助为不同的 namespace 指定确定的源 IP，这样能够在集群内部的安全设备上部署一些策略来执行管制。不言而喻，这种策略管制形式比拟粗放，无奈做到对不同服务的精细化粒度。如果 pods 扩散在不同的 nodes 上，则还会存在 pods 出集群流量要先在不同 nodes 之间穿梭问题，减少了额定的提早。此外，EgressIP 还必须与 nodes 的主网络地址同属雷同网段，且一个 node 不能够领有一个以上的 EgressIP。EgressIP 也不反对私有云以及 Redhat Openstack Platform。Egress Router Pod，它是一种非凡的 pod，领有两个网卡，应用 MacVlan 技术将其中一个容器网卡与内部网络间接连通。所有 pods 出集群流量都会通过该 pod。依据不同的 CNI（SDN 或 OVN-kubernetes）, 具备的性能也不同，在 OVN-kubernetes CNI 下仅反对重定向操作。一般来说这并不适宜大规模应用，从 Egress 安全策略设定角度，这也仍然无奈辨别不同服务，且集中的 Egress pod 容易成为性能瓶颈。EgressFirewall，它理论是 OVN-kubernetes 的个性。答应为某个 project 或 namespace 设置出向拜访规定，能够基于协定，端口，IP，DNS 等维度。协定仅反对 TCP，UDP，SCTP 三种，无奈反对其它协定管制。它只答应基于 namespace 级别设定，一个 namespace 中只答应设置一个规定文件，无奈为集群内的不同 service 来设定不同的 Egress 规定。同时它限度每个 namespace/project 最大 8000 条规定。也不反对可观测或事件。Egress NetworkPolicy，与 EgressFirewall 性能相似，当采纳 Openshift SDN CNI 时候反对该 CRD。然而 Egress NetworkPolicy 具备更多的限制性，例如每个 namespace/project 最大反对 1000 条规定，且必须关上 nework policy 或 multitennat 模式。基于 CNI 实现
以 Calico 和 Cilium 为典型代表的 CNI，在规范 k8s Network Policy 上扩大了局部能力，次要体现在：
反对全局策略（Calico，Cilium）DNS-based 策略反对（Calico 企业，Cilium)
L7 仅 HTTP 协定扩大（Calico，Cilium）Log（Calico，Cilium）扩大策略的利用对象到 pod 以外，例如 node 等（Calico，Cilium）层次化策略，角色化边界设定（Calico 企业）要实现这些能力，企业首先需应用这些 CNI。局部企业个性，例如层次化策略与角色设定、DNS 反对等须要额定购买服务。这会造成用户 CNI 技术锁定，不利于多云场景部署。Calico 在中国也没有服务销售，这些都会妨碍客户体验。在 CNI 上采取简单的安全策略，会导致在集群外部创立大量简单的规定，造成排错艰难，运维老本增大。大量的规定，也可能会导致网络性能降落。
对于 Calico Egress Pod，是一个非凡的 pod，领有固定的可路由的 SNAT 地址，当 Egress 流量从该专用 pod 流出时，携带了专用固定地址，这答应内部防火墙等安全设备基于该固定地址进行策略设定。其行为上与 Openshift 的 Egress Router pod 相似，从 Egress 安全策略设定角度，它无奈为不同服务执行细粒度的安全策略设定或成为性能瓶颈。
本文上篇介绍了为何要进行 Egress 流量策略管控、存在的挑战、业界计划剖析的前两个计划；在下周将会推出文章的下半篇，接着介绍残余计划。