当客户决定要将应用架构改变，从实体机转成虚机转成容器转向公有云，在安全方面的需求时常是不会变的。比如说企业安全政策规定对外服务之间必须要进行安全阻隔，一个业务如果出了安全状况不应横向影响到其他业务。或是一台数据库机器限制仅有指定业务的 AP 机器可以连线，其他不行。要达到上述需求有很多种做法，在虚拟化世界里当然最简单的就是微分段防火墙。想象一下，如果现在这些业务逐步都要转向容器架构，IT 建了一个 Kubernetes Cluster，这些不同的业务机器各自从实体机或虚机转为 Pod，项目建置过程中，资安单位会不会过来 Review，原本环境可以做到的安全控制，在新的容器环境内能不能达到呢？
在标准 Kubernetes 内的作法叫做 Network Policies:
![]()
以上面讨论的限制 AP 与 DB 机器间的白名单为例，我们可以撰写下面的 Network Policies 来限制 App Pods 仅能对外（egress）以 TCP 6379 port 连到 DB Pods（左方规则），而同时也限制仅有来自 App Pods 的 TCP 6379 port 网络流可以连入（ingress）DB Pods（右方规则）。
![]()
详细 YAML 文件里面的格式语法等不提，这里我要问大家：你们觉得这两条规则很好写吗？很容易维护吗？
除了采用 YAML 语法很难进行防火墙配置这个问题外，Network Policies 有很多功能限制。在 Kubernetes 内 Network Policies 的官方页面，很诚实地说明了到最新 Kubernetes 1.25 版时，Network Policies 仍尚未具备的功能。不一一说明，我们从大概 18 年开始也参与了很多客户的 K8S 生产环境初期建置，在安全控制采用 Network Policies 常会碰到的问题包括了:
- 没有 UI，以 YAML 文件的方式撰写与维护过于困难；
- Network Policies 没有安全日志（log）；
- Network Policies 无法配置 deny 规则，只能设置预设 deny。也就是说，我们不能明确地阻止网络流连线，只能用白名单规则明确地允许哪些网络流可以通过；
- Network Policies 没有顺序。管理者可以针对 Pod 设定多笔规则，但不能限制哪个规则先进行比对；
- Network Policies 仅有 L4 防火墙，没有 L7 的应用识别功能，没有 IDPS 功能。
基本上，Network Policies 仅是一个最基础的安全控管功能，但要达成上述的企业需求，就是不同 Container Network Interface 方案各出奇招，透过不同客制以及自订机制来解决。Antrea 在一开始设计时，就把安全控管列为方案重点之一（在下一篇推文我会用比较仔细的方式展示以 NSX 及 Antrea 搭配后，上述的问题怎么解决）。这里我想先很简单地用一张图回应前面举例，配置由 App Pods 到 DB Pods 开放 TCP 6379 Port ，在 NSX 搭配 Antrea 的方式下怎么做：
![]()
上图内，当我们用 NSX Manager 介接了 Kubernetes Cluster 底层的 Antrea CNI 后，防火墙管理可以移到 NSX Distributed Firewall 的管理接口运作。在上面的图内大家可以看到，配置方式就如同熟悉的 UI 管理界面，我们可以采用来源、目的地、服务、Applied To、动作 （Allow/Reject）来配置防火墙规则。红框内列出的两条规则，就分别对应到前面范例内，由App Pods 对外的 Egress 以及 DB Pods 的Ingress 两组 Network Policies。
在下一篇推文，我们会用一个更简单的例子来展示 NSX 与 Antrea 结合在安全管理上的威力，包含群组配置、规则写法、以及日志记录等等。
内容来源｜公众号：VMware 中国研发中心
本文作者：Colin Jao （饶康立）, VMware 资深技术顾问，主要负责 VMware NSX 产品线，目前致力于网络虚拟化、分布式安全防护技术与新应用递送方案的介绍与推广。
