虛擬雲網路

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

作者: 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結合在安全管理上的威力,包含群組配置、規則寫法、以及日誌記錄等等。

评论

发表评论

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

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