前篇《虚拟云网络系列 | Antrea 应用于 VMware 方案功能简介（六）》中，我们以实际画面展示了采用 NSX 搭配基于 Antrea 的 Kubernetes Cluster 内，在 NSX UI 管理界面内可以查看到 K8S 丛集的相关信息，并且可以基于 Namespace / Service / Pod Label 等，将要管理的 Pod 纳入 Antrea 群组。本篇内，同样地我想要以实际的画面与大家展示，在 NSX 内如何配置对应的 K8S 防火墙规则，并且查询相关日志。
在前篇展示内我们建立了一个叫做 dvwa-ns 的群组，把所有在 dvwa-ns namespace 内的 Pods 都加到这个群组内。接下来我们要做的展示如下：
- 在上述群组内的 Pod，可以连往任何地方，但不能连到 9.9.9.9 这个 IP 地址；
- 防火墙规则符合时，可以提供日志记录。
下图是我要实现上面的这个防火墙政策，在 NSX – Security – Policy Management – Distributed Firewall 内输入的规则：
![]()
几个重点讨论如下：
1.定义规则前，我们需要建立一个 Policy Section，也就是上图内的 TKGM-Cluster。在 Section 内，必须要特别配置 Applied To 指明这个段落内的包含的所有规则是要运作在哪个 Kubernetes Cluster 上。下面的放大图内可以看到，这个 Section 内的规则是配置到 tkgm-122-tkc03 这个丛集内的（其他的 Kubernetes Cluster 不会接收到此规则）。
![]()
2.在段落内的第一条规则（ 3052 号），配置到 dvwa-ns 这个群组上，目的地往 9.9.9.9 的网络流都设定要拒绝（ Reject ）。因此这是一条对应 dvwa-ns 这个群组内的 Pod 上面的egress 规则（对外往指定 IP 地址拒绝）。
3.在段落内的第二条规则（ 3051 号）同样配置到 dvwa-ns 这个群组上，所有的网络流都设定为允许（ Allow ）。因此这是一条对应 dvwa-ns 这个群组内的 Pod 上面的预设规则（所有其他 Traffic 都允许）。
4.在段落内，规则当然是有顺序性的，3052 号规则在上方会先比对，如果没有 match 才会比对到下方的 3051 号规则。
5.在每条规则内最后像是齿轮的图标点击时，我们可以设定这条规则是否要启用日志，如下图。
![]()
6.这样规则就设定完成了，应该很直觉。但大家不知道是否有注意到在规则配置上方，与虚机配置时一样，同样有 ETHERNET – EMERGENCY – INFRASTRUCTURE – ENVIRONMENT – APPLICATION 五个 Catogories。这五个项次和之前我们虚机微分段的概念一样，是有顺序性的，管理者可以依据不同的需求，在各项次内配置对应的规则，优先权是 Ethernet > Emergency > Infrastructure > Environment > Application。举例来说，在 Kubernetes Cluster 内每个 Pod 与服务间的相互连线，都需要查询内部的 DNS，因此若任何 Kubernetes 应用要正常运作，DNS 连线绝对不能阻挡掉。我们需要在 Infrastructure 内设定通用规则，所有 DNS Traffic 都一定要允许通过，如下图所示：
![]()
上面的配置完成后，在 NSX 接口右上角按 Publish ，NSX Manager 就会把相关规则派送到对应的 Kubernetes Cluster 内，由 Antrea 接手进行对应的 Antrea Network Policy 设定。
接着我们到受上述安全政策规范，用来展示的这个 Pod 上面。
DVWA 是一个专门用来做渗透测试与 WAF 功能展示的示范应用，利用上面的工具，我们尝试去 ping 9.9.9.9，以及另一个 168.95.1.1 两个 Internet 上的 IP 地址。大家可以看到，往 9.9.9.9 的连线被拒绝了，但往 168.95.1.1 的连线可以正常 ping 通：
![]()
![]()
可见得防火墙规则有依照上面我们的配置生效。
其次，在规则内我们有要求要启用日志。Antrea 默认会将防火墙日志放在每个 Kubernetes Nodes 内的 /var/log/antrea/networkpolicy/np.log 目录下， Kubernetes 管理者可以用不同的工具将这个 log 导出，送往集中的日志管理系统，比如说 Log Insight。在我们的展示环境内，使用 Fluentbit 套件把 log 送出，在 Log Insight 内可以看到下列的日志。首先我们搜寻往 9.9.9.9 的相关日志，可以看到由 10.61.2.10 往 9.9.9.9 的 ICMP 连线被拒绝：
![]()
接着搜寻往 168.95.1.1 的相关日志，可以看到由 10.61.2.10 往 168.95.1.1 的 ICMP 连线允许通过：
![]()
前篇我们有谈到 NSX 可以抓取 Kubernetes 里面的相关信息，当然包含 Pod 以及对应的 IP 地址。因此我们可以到 Inventory 内看这个 DVWA pod 的相关信息，很明确地，IP Address 是 10.61.2.10 没有错：
![]()
这两篇内我们用实际的画面让大家看到采用 NSX 搭配 Antrea 时，如何在 UI 管理界面内进行群组、安全政策的配置，并且能收集日志。简单的总结，与传统的 Kubernetes Network Policies 比较，采用 NSX + Antrea 的运作方式，能够：
- 以方便的图形化用户管理界面进行防火墙政策配置；
- 具备企业需求的安全日志（ log ）功能；
- 如同标准企业等级防火墙，可以明确配置 deny 规则，也可以依据顺序进行防火墙规则比对；
- 目前虽仅有 L4 防火墙，L7 及 IDPS 相关功能已经在 Antrea 的后续 Roadmap 列表上。
希望能让大家感受到 NSX + Antrea 的威力。下一篇，回到技术层面，我们要讨论一下 Antrea + NSX 的运作架构，并继续讨论安装整合的方法。
内容来源｜公众号：VMware 中国研发中心
本文作者：Colin Jao （饶康立）, VMware 资深技术顾问，主要负责 VMware NSX 产品线，目前致力于网络虚拟化、分布式安全防护技术与新应用递送方案的介绍与推广。
