使用 Calico 了解網路策略選項

使用 Calico 了解網路策略選項

Calico 網路插件提供了廣泛的網路策略和統一的語法來保護硬體主機、虛擬機器和 Pod。 這些策略可以應用在命名空間內,也可以是應用在的全域網路策略 主機端點 (保護直接在主機上運行的應用程式 - 主機可以是伺服器或虛擬機器)或 工作負載端點 (保護在容器或託管虛擬機器中執行的應用程式)。 Calico 策略可讓您使用 preDNAT、unraracked 和 applyOnForward 等選項在資料包路徑中的各個點套用安全措施。 了解這些選項的工作原理有助於提高整個系統的安全性和效能。 本文解釋了應用於主機端點的這些 Calico 策略選項(preDNAT、unraracked 和 applyOnForward)的本質,重點是封包處理路徑(iptabels 鏈)中發生的情況。

本文假設您對 Kubernetes 和 Calico 網路策略的工作原理有基本了解。 如果沒有,我們建議嘗試一下 網路策略基礎教程 и 主機保護教學 在閱讀本文之前使用 Calico。 我們也希望您對工作有基本的了解 iptables的 在linux中。

印花布 全球網路政策 允許您按標籤套用一組存取規則(到主​​機群組和工作負載/pod)。 如果您一起使用異質系統(虛擬機器、直接在硬體上的系統或 kubernetes 基礎架構),這非常有用。 此外,您可以使用一組聲明性策略來保護叢集(節點),並將網路策略套用至傳入流量(例如,透過 NodePorts 或外部 IP 服務)。

從根本上講,當 Calico 將 Pod 連接到網路時(請參閱下圖),它會使用虛擬乙太網路介面 (veth) 將其連接到主機。 Pod 發送的流量從該虛擬介面到達主機,並以與來自實體網路介面相同的方式進行處理。 預設情況下,Calico 將這些介面命名為 caliXXX。 由於流量來自虛擬接口,因此它會通過 iptables,就好像 Pod 距離一跳一樣。 因此,當流量傳入/傳出 pod 時,它是從主機的角度轉送的。

在執行 Calico 的 Kubernetes 節點上,您可以將虛擬介面 (veth) 對應到工作負載,如下所示。 在下面的範例中,您可以看到 veth#10 (calic1cbf1ca0f8) 連接到 calico-monitoring 命名空間中的 cnx-manager-*。

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m                            ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...

使用 Calico 了解網路策略選項

鑑於 Calico 為每個工作負載創建了一個 veth 接口,它如何執行策略? 為此,Calico 使用 iptables 在封包處理路徑的各個鏈中建立鉤子。

下圖顯示了 iptables(或 netfilter 子系統)中封包處理所涉及的鏈。 當封包透過網路介面到達時,它首先經過 PREROUTING 鏈。 然後做出路由決策,並基於此,資料包通過 INPUT(定向到主機程序)或 FORWARD(定向到 Pod 或網路上的另一個節點)。 從本地進程開始,封包先經過 OUTPUT,然後經過 POSTROUTING 鏈,然後透過電纜發送。

請注意,就 iptables 處理而言,pod 也是一個外部實體(連接到 veth)。 我們總結一下:

  • 轉送流量(nat、路由或往返 pod)透過 PREROUTING - FORWARD - POSTROUTING 鏈。
  • 到本地主機進程的流量通過 PREROUTING - INPUT 鏈。
  • 來自本地主機進程的流量通過 OUTPUT - POSTROUTING 鏈。

使用 Calico 了解網路策略選項

Calico 提供策略選項,讓您在所有鏈上套用策略。 考慮到這一點,讓我們看看 Calico 中可用的不同策略配置選項。 下面選項清單中的數字與上圖的數字相對應。

  1. 工作負載端點 (pod) 策略
  2. 主機端點策略
  3. 應用程式轉送選項
  4. DNAT 前政策
  5. 未追蹤的政策

我們首先了解如何將策略應用於工作負載端點(Kubernetes Pod 或 OpenStack VM),然後查看主機端點的策略選項。

工作負載端點

工作負載端點策略 (1)

這是保護您的 kubernetes pod 的選項。 Calico 支援使用 Kubernetes NetworkPolicy,但它還提供其他策略 - Calico NetworkPolicy 和 GlobalNetworkPolicy。 Calico 為每個 pod(工作負載)建立一條鏈,並在 INPUT 和 OUTPUT 鏈中將工作負載掛鉤到 FORWARD 鏈的過濾錶。

主機端點

主機端點策略 (2)

除了CNI(容器網路介面)之外,Calico策略也提供了保護主機本身的能力。 在 Calico 中,您可以透過指定主機介面和連接埠號碼(如果需要)的組合來建立主機端點。 該實體的策略實施是使用 INPUT 和 OUTPUT 鏈中的過濾表來實現的。 從圖中可以看出,(2)它們適用於節點/主機上的本機進程。 也就是說,如果您建立適用於主機端點的策略,它不會影響進出 Pod 的流量。 但它確實提供了一個介面/語法,用於使用 Calico 策略阻止主機和 Pod 的流量。 這大大簡化了管理異質網路策略的過程。 配置主機端點策略以增強叢集安全性是另一個重要的用例。

ApplyOnForward 政策 (3)

ApplyOnForward 選項在 Calico 全域網路策略中可用,允許將政策套用於透過主機端點的所有流量,包括將由主機轉送的流量。 這包括轉發到本地 Pod 或網路上其他任何地方的流量。 Calico 要求為使用 PreDNAT 和未追蹤的策略啟用此設置,請參閱以下部分。 此外,ApplyOnForward 可用於在使用虛擬路由器或軟體 NAT 的情況下監控主機流量。

請注意,如果您需要對主機進程和 Pod 套用相同的網路策略,則不需要使用 ApplyOnForward 選項。 您所需要做的就是為所需的主機端點和工作負載端點 (pod) 建立標籤。 Calico 足夠智能,可根據標籤實施策略,無論端點類型(主機端點或工作負載)為何。

PreDNAT 政策 (4)

在 Kubernetes 中,可以使用 NodePorts 選項向外部公開服務實體端口,或可選地(使用 Calico 時)透過使用 Cluster IPs 或External IPs 選項來通告它們。 Kube-proxy 使用 DNAT 將綁定到服務的傳入流量平衡到對應服務的 Pod。 有鑑於此,如何對通過 NodePort 的流量實施策略? 為了確保在 DNAT(主機:連接埠和對應服務之間的對應)處理流量之前應用這些策略,Calico 為 globalNetworkPolicy 提供了一個名為「preDNAT: true」的參數。

當啟用 pre-DNAT 時,這些策略將在圖中的 (4) 中實現 - 在 PREROUTING 鏈的 mangle 表中 - 緊接在 DNAT 之前。 這裡不遵循通常的策略順序,因為這些策略的應用在流量處理路徑中發生得更早。 然而,preDNAT 策略尊重它們之間的應用順序。

在使用 DNAT 之前建立策略時,務必小心要處理的流量並允許拒絕大多數流量。 主機端點策略將不再檢查 DNAT 前策略中標記為「允許」的流量,而 DNAT 前策略失敗的流量將繼續通過其餘鏈。
Calico 強制要求在使用 preDNAT 時啟用 applyOnForward 選項,因為根據定義尚未選擇流量的目的地。 流量可以定向到主機進程,也可以轉送到 Pod 或另一個節點。

未追蹤的政策 (5)

網路和應用程式的行為可能存在很大差異。 在某些極端情況下,應用程式可能會產生許多短期連接。 這可能會導致 conntrack(Linux 網路堆疊的核心元件)耗盡記憶體。 傳統上,要在 Linux 上運行這些類型的應用程序,您必須手動配置或停用 conntrack,或者編寫 iptables 規則來繞過 conntrack。 如果您想盡快處理連接,Calico 中的未追蹤策略是一個更簡單、更有效率的選項。 例如,如果您使用大量 內存緩存 或作為額外的保護措施 DDOS.

讀這個 博客文章 (或者 我們的翻譯)了解更多信息,包括使用未跟踪策略的性能測試。

當您在 Calico globalNetworkPolicy 中設定「doNotTrack: true」選項時,它會成為**未追蹤**策略,並在 Linux 封包處理管道中很早就套用。 從上圖可以看出,在連線追蹤 (conntrack) 啟動之前,未追蹤的策略會套用到原始表中的 PREROUTING 和 OUTPUT 鏈中。 當未追蹤策略允許某個資料包時,它會被標記為停用該資料包的連線追蹤。 它的意思是:

  • 未追蹤策略是針對每個資料包應用的。 沒有連結(或流)的概念。 缺乏聯繫會產生幾個重要的後果:
  • 如果您希望同時允許請求和回應流量,則需要針對入站和出站的規則(因為 Calico 通常使用 conntrack 將回應流量標記為允許)。
  • 未追蹤策略不適用於 Kubernetes 工作負載 (pod),因為在這種情況下,無法追蹤 pod 的傳出連線。
  • NAT 無法正確處理未追蹤的封包(因為核心將 NAT 映射儲存在 conntrack 中)。
  • 當通過未追蹤策略中的「允許所有」規則時,所有資料包將被標記為未追蹤。 這幾乎總是不是您想要的,因此對未追蹤策略允許的資料包進行嚴格篩選(並允許大多數流量通過正常的追蹤策略)非常重要。
  • 未追蹤的策略在資料包處理管道的最開始應用。 在創建 Calico 策略時了解這一點非常重要。 您可以擁有 order:1 的 pod 策略和 order:1000 的未追蹤策略。 沒關係。 Untracked 策略將在 pod 的策略之前套用。 未追蹤的策略僅尊重它們之間的執行順序。

由於 doNotTrack 策略的目的之一是在 Linux 封包處理管道中儘早強制執行該策略,因此 Calico 強制要求在使用 doNotTrack 時指定 applyOnForward 選項。 參考資料包處理圖,請注意,untracked(5) 策略在任何路由決策之前應用。 流量可以定向到主機進程,也可以轉送到 Pod 或另一個節點。

結果

我們研究了 Calico 中的各種策略選項(主機端點、ApplyOnForward、preDNAT 和 Untracked)以及它們如何沿著資料包處理路徑應用。 了解它們的工作原理有助於制定有效且安全的政策。 透過 Calico,您可以使用套用於標籤(一組節點和 Pod)的全域網路策略,並套用具有各種參數的策略。 這使得安全性和網路設計專業人員能夠使用單一策略語言和 Calico 策略,方便地同時保護「所有內容」(端點類型)。

致謝:我要感謝 肖恩·克蘭普頓 и 亞歷克薩·波利塔 以獲取他們的評論和有價值的資訊。

來源: www.habr.com

添加評論