作者：林静
职务：资深架构师
公司：F5
上周推出的《是时候思考 k8s 出向流量安全（上）》介绍了为何要进行 Egress 流量策略管控、存在的挑战、业界方案分析的前两个方案，本文将继续介绍 Egress 流量管控方案的剩余方案。
基于 Service Mesh 实现
Service Mesh 并不是 Egress 流量管控的专门方案，因此要通过 Service Mesh 实现 Egress 的管控意味着首先需要部署整体 Service Mesh 方案，比如 Istio。如果仅仅是为了实现 Egress 的管控，这样的方案会显得较重。Service Mesh 所支持的协议范围也较少，这对于企业的安全策略来说还不足够。
在 Istio 中，当设置 meshConfig.outboundTrafficPolicy.mode 为 REGISTRY_ONLY 后可以通过 sidecar 结合 ServiceEntry 资源实现外部服务访问的白名单。也可以通过结合 Egress Gateway 将流量导向到专门的 Egress Gateway。相比于 ServiceEntry 方法，Egress Gateway 则结合了 VirtualService 和 DestinationRule 来实现更多的控制，配合 AuthorizationPolicy 则可以控制粒度更细一些。
无论哪种方式，都必须依赖 sidecar 进行流量的劫持，如果有威胁绕开或破坏了 sidecar，则意味着有害访问可以直接绕开管控，这个安全问题在 Istio 的文档中被反复提及。所以本质上来说它不是一个很好的 Egress 流量管控方案。
同时，Service Mesh 的思维更多是面向开发者（尽管它常常体现的是平台层面的能力），所以我们依然需要回答这样一个问题：当开发者设置了外部服务访问白名单后，集群外部是否就可以信任开发者这样的设置，外部安全设备是否就可以设置为容许集群的任意外部访问？
微分段技术
微分段一般是 Zero Trust Architecture(ZTA) 领域热衷的概念，通过一些技术（如 TC，IPtables，DPI）对底层流量进行探查、操纵与控制，实现对容器内进程、容器间通信、容器与集群外的通信的可视化与策略控制。
一般来说会在集群的各个主机上安装 DaemonSet 类容器实现对底层流量的探查。此类方案可以基于较细的粒度进行 Egress 策略控制，例如对哪些应用相关 pods 通过哪些协议访问哪些外部服务，亦可选择诸如 Service account 或 Label 等要素。
对于应用层加密数据，如果是 Istio 环境则可通过探查 sidecar 与应用容器之间流量实现明文探查；如果是应用容器自身直接加密则无法实现探查，但可以通过结合 DNS 解析、SNI 实现一定程度上的策略管控。
融合方案
上述的多种类型方案，主要切入点是在集群内。在客户的实际生产环境中，kubernetes 集群是一种资源性对象，从企业整体安全角度来看，外部安全设备依然有必要对 kubernetes 集群的出向流量进行管控。让外部安全设备与 kubernetes 集群融合，其难点在于，传统安全设备不是直接面向 kubernetes 设计。
高动态性、IP 无关性会成为传统设备进行 kubernetes 出向流量管控的难点。但这并不是无法解决的技术难题，如果外部安全设备具有较好的 API 接口，通过专门设计的控制器则可以解决上述技术难题。这样，外部安全防护的措施便可以应用到kubernetes 集群上来，形成完整的纵深防御体系。
同时可以保护企业已有投资，节约成本。通过面向 kubernetes 的自定义资源类型设计，负责外部安全设备的团队也因此可以介入到 kubernetes 集群的整体安全工作中来，避免了团队的割裂。
F5 的 Application Firewall Manager(AFM) 通过专用的免费控制器（CES）实现了以 kubernetes 原生自定义资源（CRD）方式进行 Egress 策略的控制，并实现了安全规则与角色的层次化设定，让安全设备管理员融合到了 kubernetes 平台。借助 AFM 的能力，可实现 Egress 流量的高级访问规则、限流、协议检查、日志与事件可视化等。
Fortinet 自身以及与 Calico 企业版联合，也实现了与kubernetes 的集成，但其主要特点是将 kubernetes 资源对象转化并写入 Fortinet 的地址组中，其管理视角依然是防火墙管理员视角，而不是 kubernetes native 方式。
其他
Proxy pod 是一种普通的正向代理，应用使用该代理实现对外部业务的访问。此种方式一般仅适合小规模场景，不适合大规模集群及复杂业务。
DNS interception，其原理是通过 patch coredns，如果应用访问 ExternalService 对象中设定的外部服务，则将请求引导到一个专用的 proxy pod 上（例如 Envoy 等）实现对流量的处理。该方案同样不适合大规模场景。
在完成对 6 类 Egress 流量管控方案的分析后，让我们来总结和对比一下这些方案的优缺点：
可以看出 Network Policy 虽然是一个 kubernetes 原生的方式，但显然并不适合于集群 Egress 流量的管控。CNI 类产品有了一定的增强，但是在协议检测、企业级支持方面还是不够。
微分段类产品具有相对完整的能力，但是微分段是一个整体性的解决方案，仅仅使用微分段实现集群出向流量的管控会显得投入较大，且微分段的产品一般底层技术较为复杂，运维难度较高。
将外部安全设施融入到 kubernetes 当中实现出向流量管控的解决方法更加适合企业，无论是功能特性还是运维复杂度都比较适合，更加重要的是，该类方案将企业的传统安全资产与现代应用架构进行了结合，让不同部门能够紧密协同，形成纵深防御体系。
总结
我们往往重视 Ingress 的能力，而忽视了 Egress 流量的安全管控。但无论从安全还是合规的角度，Egress 流量都应加强管控。当漏洞已经侵入应用后，Egress 流量管控往往是最后一个保护的关口。在上当前众多方案中，大部分的方案是基于kubernetes 内的 Network Policy 实现，有的依赖于特定的 CNI，有的依赖于特定的编排平台。
但当我们从企业的整体安全架构去考虑时，将外部安全设备引入到 kubernetes 安全体系当中一件非常必要的事情，只有这样才能实现真正的全面防御。而当我们讨论 DevSecOps 时，需要让开发、平台、安全乃至网络这些不同团队同时参与到整体安全工作中，实现跨团队的紧密协作。