當客戶決定要將應用架構改變，從實體機轉成虛機轉成容器轉向公有云，在安全方面的需求時常是不會變的。比如說企業安全政策規定對外服務之間必須要進行安全阻隔，一個業務如果出了安全狀況不應橫向影響到其他業務。或是一臺數據庫機器限制僅有指定業務的 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 產品線，目前致力於網絡虛擬化、分佈式安全防護技術與新應用遞送方案的介紹與推廣。