作者：林静
职务：资深架构师
公司：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 时，须要让开发、平台、平安乃至网络这些不同团队同时参加到整体平安工作中，实现跨团队的严密合作。