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

作為本系列文的最後一篇,我想以Q&A的方式,來回答在與客戶與經銷夥伴介紹以NSX防火牆提供Kubernetes南北向防護時,常被問到的各種問題,也希望在相關的討論中讓大家對此功能更加地了解。

要使用NSX整合Kubernetes叢集提供南北向防護時,有哪些產品與授權的前置需求?

首先,因為這個方案是以NSX Manager整合VMware Container Networking with Antrea方案來抓取Kubernetes南北向物件相關資訊,因此當然在相關方案規劃內

  • Kubernetes叢集內之Container Network Interface必須要選擇採用VMware Container Networking with Antrea,而且需要使用商用版本1.6以上版本。
  • 必須要有具備VMware NSX,並透過NSX之閘道或分散式防火牆進行安全保護,且NSX需支持Container Networking功能。簡而言之,企業需要具備VMware NSX Advanced以上的產品授權,且安裝4.1之後的版本。

目前在以Tanzu部署Kubernetes叢集時,上述的功能是否就已經可以使用?

在本文寫作的時間點,雖然NSX已經是4.1版本且VMware Container Networking with Antrea 1.6均已經推出,但無論是TKG 2.0 / 2.1版本所部署出的TKC (Tanzu Kubernetes Cluster) 1.23 or 1.24版本內的內建Antrea,都還尚未支持到上述的VMware Container Networking with Antrea 1.6版本。但我猜想應該在本文刊出時,TKC 1.25以上的版本或許就有機會可以搭配上述構件,可支持此功能了,也敬請大家期待。

使用此功能時,在架構上有哪些需要注意的地方?

我們要使用NSX的防火牆來做Kubernetes叢集南北向防護,此時當然,防火牆如果要生效,

  • 從用戶連往位於Kubernetes Cluster的網路流,必須要能通過NSX閘道或分散式防火牆。
  • 從K8S Pod連往企業服務或資料庫的網路流,必須要能通過NSX閘道或分散式防火牆。

也就是說在架構規劃上,NSX的防火牆務必至少要出現在下面三個位置中的一種:

  • 外部的用戶機器或是受保護的資料庫或企業服務前面(比如說以分散式防火牆保護這些虛機)。
  • 外部的用戶機器或是受保護的資料庫或企業服務,以及與Kubernetes Cluster之間的網路途徑上(採用閘道式防火牆)。
  • Kubernetes Node前面(比如說K8S Node部署在受NSX分散式防火牆防護的VLAN or Overlay Segment上)。

這裡我想特別提醒一點大家在架構規劃上要想清楚的,就是某些Kubernetes Cluster的南北向物件,『其實不見得位在Kubernetes Cluster上』。舉個例子,如果大家使用像是NSX Advanced Load Balancer (Avi) 搭配Kubernetes來配置 Ingress / LB Service / Gateway,這些服務的Frontend IP其實是位在NSX ALB的『服務引擎』上。所以比如說現在管理者設了一條防火牆規則要限制那些用戶機器可以連往Ingress,卻配置在K8S Node前面的分散式防火牆…那就無法生效了,因為Client to Ingress的網路流不會直接經過K8S Node前面。

因此使用此功能時,除了NSX Manager部署外,還需要進行 vSphereEdge的安裝嗎?

是的,因為使用此功能時我們實際上是使用DFW或是閘道防火牆來進行真正的防禦,所以NSX安裝時除了控制層,也必須依照防護需求,若要使用分散式防火牆,就要在vSphere內配置NSX元件;而若要採用閘道式防火牆,就需要安裝Edge然後配置T0/T1 Gateway。

這個功能與NSX整合Antrea提供Pod的東西向安全防護機制,是否為互斥?

當然不是,相反地,這兩個功能應該是相互配合、協同作業的:

  • 藉由NSX介面配置Antrea Policy來保護每一個容器,做到Pod等級的微分段,也就是Kubernetes叢集內服務 / Pod之間的東西向防護。
  • 透過NSX取用Kubernetes Cluster的南北向物件,提供K8S叢集與用戶或企業網路之間的南北向保護。

並且上述兩種機制是使用相同產品(VMware NSX / Antrea)及授權即可啟用的共通功能,沒有額外投資。因此我們建議客戶直接在容器環境內將兩個功能都運作起來,提供由南北向到東西向的完善保護。

使用NSX的防火牆和我直接採用實體防火牆來進行K8S叢集南北向保護,有什麼差異?

其實NSX整合K8S南北向物件就是取得這些物件的IP地址,然後運用在防火牆規則內。所以當然,企業安全管理者一定可以用標準IP的方式,在傳統實體防火牆內下IP規則來限制Kubernetes Cluster的出入網路流。但採用NSX的防火牆有下面強大優勢:

  • 要配置NSX / Antrea進行東西向防護時,客戶就已經採購NSX授權了。此時,企業可以用原本的投資,直接支持南北向的防護需求,無需額外採購及配置實體防火牆
  • NSX防火牆的群組物件可以用動態條件配置,這代表在相關物件還沒實際部署出來前,我們就可以先設好防火牆規則(而不用管真正的IP到底是什麼)。比如說以Ingress舉例。大部分的Kubernetes Ingress方案,Ingress對應的IP是不能事先選擇的,要配置完成後才會知道。此時如果採用實體防火牆,就必須等待Ingress真的配置完,才能開始申請、進行設定。但NSX防火牆就無此問題,群組內的Ingress物件可以先設定好(比如說基於名稱),防火牆規則也可以先採用上述的群組。等Ingress在Kubernetes叢集內真正配置完成,NSX自動抓到Ingress物件對應的IP,此時防火牆規則無需異動就自動生效了
  • 同樣的,由於NSX Group採用動態物件,因此比如當Kubernetes Cluster Node進行擴充等異動時,也可以自動抓到所有新的Node IP。而採用實體防火牆時,就得要重新去設防火牆規則了。

希望由上述的Q&A相關討論,能夠讓大家對NSX防火牆整合K8S叢集提供南北向防護功能,有進一步的了解與認識。近年在各個客戶做Kubernetes方案規劃及部署時,網路安全都是無可避免、需要詳細討論的課題;VMware NSX搭配VMware Container Networking with Antrea可以提供企業Kubernetes環境由東西至南北向網路完善安全保護,也歡迎大家能多加運用。