虛擬雲網路

網路虛擬化NSX 技術文章系列二百八十三: Antrea應用於VMware方案功能簡介(六)

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

接續前篇對於現行Kubernetes Network Policies的限制討論,從本篇開始我想要用實際的畫面與大家展示Antrea搭配NSX Manager如何來進行等同於企業等級防火牆的Kubernetes Pods間安全阻隔功能。相關的Antrea搭配NSX的架構與安裝機制會於後續網誌再討論,但這裡我想先針對Antrea + NSX的方案內是如何改善前面討論到的Network Policies相關缺點進行討論,包括了:

  • 採用YAML檔的方式撰寫與維護安全政策過於困難
  • 沒有安全日誌 (log)
  • Network Policies無法配置deny規則,只能設置預設deny。也就是說,我們不能明確地阻止網路流連線,只能用白名單規則明確地允許哪些網路流可以通過
  • Network Policies沒有順序。管理者可以針對Pod設定多筆規則,但不能限制哪個規則先進行比對

當我們建立了一個底層採用Antrea的Kubernetes Cluster,並完成與NSX Manager間的整合安裝步驟。此時管理者直接在NSX的UI介面內就可以看到控管的Kubernetes Cluster相關資訊了。下圖內是展示環境的畫面,在 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等,都能夠明確列出來:

下面兩張圖列出當我們點擊畫面裡的Namespaces還有Pods時列出的資訊。在圖內特別紅框的是後續用來展示用的pod (dvwa-deployment-7767887f6f-gvmpv) 以及所在的Namespace (dvwa-ns)。大家可以看到包含pod內每個Labels也都有列出:

上圖內大家可以看到的是當Antrea與NSX整合完成,NSX Manager可以取得Kubernetes Cluster內的完整構件資訊。這代表的是我們能夠透過NSX的UI介面,依據實際的應用部署,基於Namespace / Service / Pod Label等來定義要配置防火牆規則的群組,就如同我們在虛機採用微分段動態安全群組的方法一樣。在 Inventory / Group內,管理者可以配置一個基於Antrea的群組,下面兩個圖內,我們建立了一個叫做dvwa-ns的Antrea群組,群組內包含了展示pod (dvwa-deployment-7767887f6f-gvmpv),而這個群組的定義條件是採用只要任何一個在dvwa-ns這個namespace內的Pod,都要加入這個群組:

在我們要在NSX內定義一個Antrea的群組時,下列兩點需要注意:

  • 在配置群組時,要選擇Group Type是Antrea。在目前的版本, 我們還不能建立一個群組內同時包含虛機以及容器,我們必須指定這個群組是一個Antrea Group的型態
  • Antrea的群組裡面可以包含兩種模式:透過Namespace / Service / Pod Label來動態選擇Pod,或是明確的定義一個IP範圍

在下圖內大家可以看到,如果我們在群組內建立Pod選取的條件,總共有三個方式:

  • 可以將某個Namespace內的所有Pod都加入此群組,這個Namespace可以透過名稱 (Name) 或是標籤 (Namespace Label) 來定義
  • 可以將包含於某個Service內的所有Pod都加入此群組,這個Service可以透過名稱 (Name) 來定義
  • 可以透過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內的防火牆政策設定了,在下篇網誌內會繼續與大家討論。

评论

发表评论

电子邮件地址不会被公开。

This site uses Akismet to reduce spam. Learn how your comment data is processed.