前篇《虛擬雲網絡系列 | 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 產品線，目前致力於網絡虛擬化、分佈式安全防護技術與新應用遞送方案的介紹與推廣。