本文為本系列文章的第二篇，將先說明Kubernetes內傳統的Network Policies運作限制，然後再利用實際的畫面讓大家看到採用NSX搭配Antrea時，如何在UI管理介面中進行群組、安全政策的配置，並且還能夠收集日誌。
當客戶決定要將應用架構改變，從實體機轉成虛機轉成容器轉向公有雲，架構改變很大，但資安面的需求時常是不會變的。比如說企業安全政策規定對外服務之間必須要進行安全阻隔，一個業務如果出了安全狀況，不應該能橫向影響到其他業務。或是一台資料庫機器限制僅有指定業務的AP機器可以連線過來，其他不行。
要達到上述的需求有很多種做法，在虛擬化世界裡面當然最簡單的就是微分段防火牆。想像一下，如果現在這些業務逐步都要轉向容器架構，IT建了一個Kubernetes Cluster，這些不同的業務機器各自從實體機或虛機轉為Pod，專案建置過程中，資安單位會不會過來Review，原本環境可以做到的安全控制，在新的容器環境內能不能達到呢？
傳統Network Policies運作
在標準Kubernetes內的做法叫做Network Policies（https://kubernetes.io/docs/concepts/services-networking/network-policies/）。以上面討論的限制AP與DB機器間的白名單為例，可以撰寫如圖1所示的Network Policies來限制App Pods僅能對外（Egress）以TCP 6379 Port連到DB Pods（左方規則），而同時也限制僅有來自App Pods的TCP 6379 Port網路流可以連入（Ingress）DB Pods（右方規則）。
圖1 撰寫Network Policies來規範App Pods。
詳細YAML檔裡面的格式語法等就不提了，請問大家，覺得這兩條規則很好寫嗎？很容易維護嗎？
除了採用YAML語法很難進行防火牆配置這個問題外，Network Policies有很多功能限制。在Kubernetes內Network Policies的官方頁面（上面有寫的那個鏈結），也很誠實地說明了到目前最新的Kubernetes版本Network Policies仍尚未具備的功能。從大概2018年開始參與了很多客戶的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在一開始設計時，就把安全控管列為方案重點之一。這裡先簡單地用一張圖回應前面舉例的情況，配置由App Pods到DB Pods開放TCP 6379 Port，在VMware NSX搭配Antrea的方式下該怎麼做：
在圖2中，當用NSX Manager介接了Kubernetes Cluster底層的Antrea CNI後，防火牆管理可以移到NSX Distributed Firewall的管理介面運作。由圖2中可以看到，配置方式就如同熟悉的UI管理介面，可以採用來源、目的地、服務、Applied To、動作（Allow/Reject）來配置防火牆規則。方框內列出的兩條規則，就分別對應到前面範例中，由App Pods對外的Egress以及DB Pods的Ingress兩組Network Policies。
圖2 配置防火牆規則。
Antrea搭配NSX Manager
接下來，想進一步展示Antrea搭配NSX Manager如何來進行等同於企業等級防火牆的Kubernetes Pods間安全阻隔功能。首先，建立一個底層採用Antrea的Kubernetes Cluster，並完成與NSX Manager間的整合安裝步驟。此時，管理者直接在NSX的UI介面內就可以看到控管的Kubernetes Cluster相關資訊。
圖3所示是展示環境的畫面，在Inventory - Containers內，可以看到這個NSX Manager管理了三個Kubernetes Cluster，分別是來自Tanzu Kubernetes Grid、vSphere with Tanzu以及原生Kubernetes。圖中針對tkgm-122-tkc03這個由Tanzu Kubernetes Grid建立的K8s叢集，當點開來看，包含Antrea本身使用的版本，以及叢集相關的Inventory包含裡面有幾個Nodes、Pods、Services、Namespaces等，都能夠明確列出來了。
圖3 展示環境範例。
圖4列出當點擊畫面裡的Namespaces還有Pods時列出的資訊。在圖中特別框選的部分是後續用來展示用的Pod（dvwa-deployment-7767887f6f-gvmpv）以及所在的Namespace（dvwa-ns），可以看到包含Pod內每個Labels也都有列出。
圖4 點擊Namespaces和Pods時所列出的資訊。
從圖4大家可以看到的是，當Antrea與NSX整合完成，NSX Manager可以取得Kubernetes Cluster內的完整構件資訊。這代表能夠透過NSX的UI介面，依據實際的應用部署，基於Namespace、Service、Pod Label等來定義要配置防火牆規則的群組，就如同在虛機採用微分段動態安全群組的方法一樣。
配置群組
在Inventory/Group內，管理者可以配置一個基於Antrea的群組。如圖5所示，建立一個叫做dvwa-ns的Antrea群組，群組內包含了展示Pod（dvwa-deployment-7767887f6f-gvmpv），而這個群組的定義條件是採用只要任何一個在dvwa-ns這個Namespace內的Pod，都要加入這個群組。
圖5 建立一個名為dvwa-ns的Antrea群組。
要在NSX內定義一個Antrea的群組時，下列兩點需要注意：
1.在配置群組時，要選擇Group Type是Antrea。在目前的版本，還不能建立一個群組內同時包含虛機和容器，必須指定這個群組是一個Antrea Group的型態。
2. Antrea的群組裡面可以包含兩種模式：透過Namespace、Service、Pod Label來動態選擇Pod，或是明確定義一個IP範圍。
如圖6所示，在群組內建立Pod選取的條件，總共有三個方式：
圖6 在群組內建立Pod選取的條件。
1.可以將某個Namespace內的所有Pod都加入此群組，這個Namespace可以透過名稱（Name）或是標籤（Namespace Label）來定義。
2.可以將包含於某個Service內的所有Pod都加入此群組，這個Service可以透過名稱（Name）來定義。
3.可以透過Pod標籤定義（Pod Label）來選擇那些Pod要加入此群組。
請大家回憶一下之前進行虛機微分段的流程。首先，NSX透過與vCenter/vSphere接取，可以看到所有虛機的名稱、作業系統、IP Address等資訊。管理者也可以手動或透過自動化工具，在每個虛機上面打安全標籤（Tag）。然後，能夠建立群組，藉由指定虛機，或是透過標籤、名稱、作業系統等等條件，納入需要控管的虛機。最後，就能將這些群組運用在防火牆的來源、目的、Apply-To等欄位內進行政策配置了。
而在透過NSX介面來管理Kubernetes Cluster時，NSX可以直接取得K8s叢集內的Pod、Service、Namespace、Labels等資訊。安全管理者不需要在NSX介面內打標籤，K8s管理者在建立Pod/Deployment時就可以直接將相關的Label配置進去。然後，同樣地在NSX內就可以基於上面的條件建立對應的Antrea群組，來應用到防火牆政策內。
配置安全政策
群組配置完成後，接下來就可以在NSX Distributed Firewall內進行Kubernetes Cluster內的防火牆政策設定，並且查詢相關的日誌。在上面展示內建立了一個名為dvwa-ns的群組，把所有在dvwa-ns namespace內的Pods都加到這個群組中。接下來要做的展示如下：
‧在上述群組內的Pod，可以連往任何地方，但不能連到9.9.9.9這個IP地址。
‧防火牆規則符合時，可以提供日誌記錄。
圖7所示就是要實現以上的這個防火牆政策，在NSX - Security - Policy Management - Distributed Firewall內輸入的規則。幾個重點討論如下：
圖7 在Distributed Firewall內設定規則。
1.定義規則前，必須建立一個Policy Section，也就是圖7內的TKGM-Cluster。在Section內，必須要特別配置Applied To指明這個段落內包含的所有規則是要運作在哪個Kubernetes Cluster上。從圖8的放大圖中可以看到，這個Section內的規則是配置到tkgm-122-tkc03叢集內（其他的Kubernetes Cluster不會接收到此規則）。
圖8 規則細部設定範例。
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號規則在上方會先比對，如果沒有吻合才會比對到下方的3051號規則。
5.若點擊每條規則內最後像是齒輪的圖示時，可以設定這條規則是否要啟用日誌，如圖9所示。
圖9 設定規則是否要啟用日誌。
6.這樣規則就設定完成了，應該很直覺。但大家不知道是否有注意到在規則配置上方，與虛機配置時一樣，同樣有ETHERNET、EMERGENCY、INFRASTRUCTURE、ENVIRONMENT、APPLICATION五個Catogories。這五個項次和之前虛機微分段的概念一樣，是有順序性的，管理者可以依據不同的需求，在各項次內配置對應的規則，優先權是Ethernet > Emergency > Infrastructure > Environment > Application。
舉例來說，在Kubernetes Cluster內每個Pod與服務間的相互連線，都需要查詢內部的DNS，因此若任何Kubernetes應用要正常運作，DNS連線絕對不能阻擋掉。在Infrastructure內設定通用規則時，所有DNS Traffic都一定要允許通過，如圖10所示。
圖10 在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網際網路上的IP地址。如圖11所示，可以看到往9.9.9.9的連線被拒絕了，但往168.95.1.1的連線可以正常ping通，有此可見，防火牆規則有依照上面的配置生效。
圖11 ping 9.9.9.9和168.95.1.1，前者連線被拒絕，後者則可連通。
收集日誌
其次，在規則內有要求要啟用日誌。Antrea預設會將防火牆日誌放在每個Kubernetes Nodes內的「/var/log/antrea/networkpolicy/np.log」目錄中，Kubernetes管理者可以用不同的工具將這個Log導出，送往集中的日誌管理系統，例如Log Insight。在展示環境內，使用Fluentbit套件把Log送出，在Log Insight內可以檢視到相關的日誌。如圖12所示，先搜尋往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連線允許通過（圖13）。
圖12 由10.61.2.10往9.9.9.9的ICMP連線被拒絕。
圖13 由10.61.2.10往168.95.1.1的ICMP連線允許通過。
前面的段落有談到NSX可以抓取Kubernetes裡面的相關資訊，當然包含Pod及對應的IP地址，因此可以到Inventory內看這個DVWA Pod的相關資訊，很明確地，IP Address是10.61.2.10沒有錯（圖14）。
圖14 到Inventory內查看DVWA Pod的相關資訊。
結語
本文先說明了Kubernetes內傳統的Network Policies運作限制，再用實際的畫面讓大家看到採用NSX搭配Antrea時，如何在UI管理介面內進行群組、安全政策的配置，並且能夠收集日誌。簡單地總結，與傳統的Kubernetes Network Policies比較，採用NSX + Antrea的運作方式，能夠達到以下的效益：
‧以方便的圖形化用戶管理介面進行防火牆政策配置。
‧具備企業需求的安全日誌功能。
‧如同標準企業等級防火牆，可以明確配置Deny規則，也可以依據順序進行防火牆規則比對。
‧目前雖僅有L4防火牆，L7以及IDPS相關功能已經在Antrea的後續Roadmap列表上。
希望能讓大家感受到VMware NSX + Antrea的威力。下一篇文章回到技術層面，與大家說明Antrea + NSX的運作架構，並繼續討論安裝整合的方法。
＜本文作者：饒康立，VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、軟體定義網路、微分段安全防護技術，以及新應用遞送方案的介紹與推廣。＞