作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。

當客戶決定要將應用架構改變，從實體機轉成虛機轉成容器轉向公有雲，在安全面的需求時常是不會變的。比如說企業安全政策規定對外服務之間必須要進行安全阻隔，一個業務如果出了安全狀況不應該能橫向影響到其他業務。或是一台資料庫機器限制僅有指定業務的AP機器可以連線過來，其他不行。要達到上述的需求有很多種做法，在虛擬化世界裡面當然最簡單的就是微分段防火牆。想像一下，如果現在這些業務逐步都要轉向容器架構，IT建了一個Kubernetes Cluster，這些不同的業務機器各自從實體機或虛機轉為Pod，專案建置過程中，資安單位會不會過來Review，原本環境可以做到的安全控制，在新的容器環境內能不能達到呢？

在標準Kubernetes內的作法叫做Network Policies ( https://kubernetes.io/docs/concepts/services-networking/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結合在安全管理上的威力，包含群組配置、規則寫法、以及日誌記錄等等。