Das Calico-Netzwerk-Plugin bietet eine breite Palette von Netzwerkrichtlinien mit einer einheitlichen Syntax zum Schutz von Hardware-Hosts, virtuellen Maschinen und Pods. Diese Richtlinien können innerhalb eines Namespace angewendet werden oder globale Netzwerkrichtlinien sein, die für gelten (um Anwendungen zu schützen, die direkt auf dem Host ausgeführt werden – der Host kann ein Server oder eine virtuelle Maschine sein) oder (um Anwendungen zu schützen, die in Containern oder gehosteten virtuellen Maschinen ausgeführt werden). Calico-Richtlinien ermöglichen Ihnen die Anwendung von Sicherheitsmaßnahmen an verschiedenen Punkten im Pfad eines Pakets mithilfe von Optionen wie preDNAT, unraracked und applyOnForward. Wenn Sie verstehen, wie diese Optionen funktionieren, können Sie die Sicherheit und Leistung Ihres Gesamtsystems verbessern. In diesem Artikel wird das Wesentliche dieser Calico-Richtlinienoptionen (preDNAT, unraracked und applyOnForward) erläutert, die auf Host-Endpunkte angewendet werden, wobei der Schwerpunkt auf dem liegt, was in Paketverarbeitungspfaden (iptabels-Ketten) geschieht.
In diesem Artikel wird davon ausgegangen, dass Sie über ein grundlegendes Verständnis der Funktionsweise von Kubernetes- und Calico-Netzwerkrichtlinien verfügen. Wenn nicht, empfehlen wir Ihnen, es auszuprobieren и Verwenden Sie Calico, bevor Sie diesen Artikel lesen. Wir erwarten außerdem, dass Sie über ein grundlegendes Verständnis der Arbeit verfügen unter Linux.
Kattun ermöglicht Ihnen die Anwendung einer Reihe von Zugriffsregeln nach Labels (auf Gruppen von Hosts und Workloads/Pods). Dies ist sehr nützlich, wenn Sie heterogene Systeme gemeinsam nutzen – virtuelle Maschinen, ein System direkt auf Hardware oder eine Kubernetes-Infrastruktur. Darüber hinaus können Sie Ihren Cluster (Knoten) mithilfe einer Reihe deklarativer Richtlinien schützen und Netzwerkrichtlinien auf eingehenden Datenverkehr anwenden (z. B. über den NodePorts- oder External IPs-Dienst).
Wenn Calico einen Pod mit dem Netzwerk verbindet (siehe Abbildung unten), verbindet es ihn grundsätzlich über eine virtuelle Ethernet-Schnittstelle (veth) mit dem Host. Der vom Pod gesendete Datenverkehr kommt von dieser virtuellen Schnittstelle zum Host und wird auf die gleiche Weise verarbeitet, als ob er von einer physischen Netzwerkschnittstelle käme. Standardmäßig nennt Calico diese Schnittstellen caliXXX. Da der Datenverkehr über die virtuelle Schnittstelle erfolgt, läuft er über iptables, als wäre der Pod nur einen Sprung entfernt. Wenn Datenverkehr zu/von einem Pod kommt, wird er daher aus der Sicht des Hosts weitergeleitet.
Auf einem Kubernetes-Knoten, auf dem Calico ausgeführt wird, können Sie einer Arbeitslast wie folgt eine virtuelle Schnittstelle (veth) zuordnen. Im folgenden Beispiel können Sie sehen, dass veth#10 (calic1cbf1ca0f8) mit cnx-manager-* im Calico-Monitoring-Namespace verbunden ist.
[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
...
Da Calico für jeden Workload eine Veth-Schnittstelle erstellt, wie setzt Calico Richtlinien durch? Dazu erstellt Calico mithilfe von iptables Hooks in verschiedenen Ketten des Paketverarbeitungspfads.
Das Diagramm unten zeigt die Ketten, die an der Paketverarbeitung in iptables (oder dem Netfilter-Subsystem) beteiligt sind. Wenn ein Paket über eine Netzwerkschnittstelle ankommt, durchläuft es zunächst die PREROUTING-Kette. Anschließend wird eine Routing-Entscheidung getroffen und auf dieser Grundlage wird das Paket entweder über INPUT (an Host-Prozesse weitergeleitet) oder FORWARD (an einen Pod oder einen anderen Knoten im Netzwerk weitergeleitet) weitergeleitet. Vom lokalen Prozess aus durchläuft das Paket die OUTPUT- und dann die POSTROUTING-Kette, bevor es über das Kabel gesendet wird.
Beachten Sie, dass der Pod im Hinblick auf die iptables-Verarbeitung auch eine externe Entität (verbunden mit dem Veth) ist. Fassen wir zusammen:
- Weitergeleiteter Datenverkehr (nat, weitergeleitet oder zu/von einem Pod) durchläuft die Ketten PREROUTING – FORWARD – POSTROUTING.
- Der Datenverkehr zum lokalen Hostprozess durchläuft die PREROUTING-INPUT-Kette.
- Der Datenverkehr vom lokalen Hostprozess durchläuft die OUTPUT-POSTROUTING-Kette.
Calico bietet Richtlinienoptionen, mit denen Sie Richtlinien über alle Ketten hinweg anwenden können. Schauen wir uns vor diesem Hintergrund die verschiedenen Optionen zur Richtlinienkonfiguration an, die in Calico verfügbar sind. Die Zahlen in der Liste der Optionen unten entsprechen den Zahlen im Diagramm oben.
- Workload-Endpunkt-(Pod-)Richtlinie
- Host-Endpunktrichtlinie
- ApplyOnForward-Option
- PreDNAT-Richtlinie
- Nicht verfolgte Richtlinie
Schauen wir uns zunächst an, wie Richtlinien auf Workload-Endpunkte (Kubernetes-Pods oder OpenStack-VMs) angewendet werden, und schauen wir uns dann die Richtlinienoptionen für Host-Endpunkte an.
Workload-Endpunkte
Workload-Endpunktrichtlinie (1)
Dies ist eine Option zum Schutz Ihrer Kubernetes-Pods. Calico unterstützt die Arbeit mit Kubernetes NetworkPolicy, bietet aber auch zusätzliche Richtlinien – Calico NetworkPolicy und GlobalNetworkPolicy. Calico erstellt eine Kette für jeden Pod (Arbeitslast) und hängt die INPUT- und OUTPUT-Ketten für die Arbeitslast an die Filtertabelle der FORWARD-Kette an.
Host-Endpunkte
Host-Endpunkt-Richtlinie (2)
Zusätzlich zu CNI (Container Network Interface) bieten Calico-Richtlinien die Möglichkeit, den Host selbst zu schützen. In Calico können Sie einen Host-Endpunkt erstellen, indem Sie eine Kombination aus Host-Schnittstelle und, falls erforderlich, Portnummern angeben. Die Durchsetzung der Richtlinien für diese Entität wird mithilfe einer Filtertabelle in den INPUT- und OUTPUT-Ketten erreicht. Wie Sie dem Diagramm entnehmen können, gelten (2) sie für lokale Prozesse auf dem Knoten/Host. Das heißt, wenn Sie eine Richtlinie erstellen, die für den Host-Endpunkt gilt, hat dies keinen Einfluss auf den Datenverkehr, der zu/von Ihren Pods geht. Es bietet jedoch eine einzige Schnittstelle/Syntax zum Blockieren des Datenverkehrs für Ihren Host und Ihre Pods mithilfe von Calico-Richtlinien. Dies vereinfacht die Verwaltung von Richtlinien für ein heterogenes Netzwerk erheblich. Ein weiterer wichtiger Anwendungsfall ist die Konfiguration von Host-Endpunktrichtlinien zur Verbesserung der Clustersicherheit.
ApplyOnForward-Richtlinie (3)
Die Option „ApplyOnForward“ ist in der globalen Netzwerkrichtlinie von Calico verfügbar, um die Anwendung von Richtlinien auf den gesamten Datenverkehr zu ermöglichen, der den Host-Endpunkt passiert, einschließlich des Datenverkehrs, der vom Host weitergeleitet wird. Dazu gehört der Datenverkehr, der an den lokalen Pod oder irgendwo anders im Netzwerk weitergeleitet wird. Für Calico muss diese Einstellung für Richtlinien aktiviert sein, die PreDNAT verwenden und nicht verfolgt werden. Weitere Informationen finden Sie in den folgenden Abschnitten. Darüber hinaus kann ApplyOnForward zur Überwachung des Host-Verkehrs verwendet werden, wenn ein virtueller Router oder Software-NAT verwendet wird.
Beachten Sie, dass Sie die Option ApplyOnForward nicht verwenden müssen, wenn Sie dieselbe Netzwerkrichtlinie sowohl auf Hostprozesse als auch auf Pods anwenden müssen. Sie müssen lediglich eine Bezeichnung für den erforderlichen Hostendpunkt und Workload-Endpunkt (Pod) erstellen. Calico ist intelligent genug, um Richtlinien basierend auf Labels durchzusetzen, unabhängig vom Endpunkttyp (Hostendpunkt oder Workload).
PreDNAT-Richtlinie (4)
In Kubernetes können Service-Entity-Ports mithilfe der Option „NodePorts“ oder optional (bei Verwendung von Calico) durch Ankündigen mithilfe der Optionen „Cluster-IPs“ oder „Externe IPs“ extern verfügbar gemacht werden. Kube-Proxy gleicht eingehenden Datenverkehr, der an einen Dienst gebunden ist, mithilfe von DNAT an die Pods des entsprechenden Dienstes aus. Wie setzen Sie vor diesem Hintergrund Richtlinien für den Datenverkehr durch, der über NodePorts kommt? Um sicherzustellen, dass diese Richtlinien angewendet werden, bevor der Datenverkehr von DNAT verarbeitet wird (bei dem es sich um eine Zuordnung zwischen Host:Port und dem entsprechenden Dienst handelt), stellt Calico einen Parameter für globalNetworkPolicy mit dem Namen „preDNAT: true“ bereit.
Wenn Pre-DNAT aktiviert ist, werden diese Richtlinien in (4) im Diagramm implementiert – in der Mangle-Tabelle der PREROUTING-Kette – unmittelbar vor DNAT. Die übliche Reihenfolge der Richtlinien wird hier nicht eingehalten, da die Anwendung dieser Richtlinien viel früher im Verkehrsverarbeitungspfad erfolgt. Die preDNAT-Richtlinien respektieren jedoch die Reihenfolge der Anwendung untereinander.
Beim Erstellen von Richtlinien mit Pre-DNAT ist es wichtig, sorgfältig auf den Datenverkehr zu achten, den Sie verarbeiten möchten, und zuzulassen, dass der Großteil abgelehnt wird. Datenverkehr, der in der Vor-DNAT-Richtlinie als „Zulassen“ gekennzeichnet ist, wird nicht mehr von der Hostendpoint-Richtlinie überprüft, während Datenverkehr, der die Vor-DNAT-Richtlinie nicht erfüllt, durch die verbleibenden Ketten weitergeführt wird.
Calico hat die Aktivierung der Option „applyOnForward“ bei Verwendung von preDNAT zwingend vorgeschrieben, da das Ziel des Datenverkehrs per Definition noch nicht ausgewählt wurde. Der Datenverkehr kann an den Hostprozess weitergeleitet oder an einen Pod oder einen anderen Knoten weitergeleitet werden.
Nicht verfolgte Richtlinie (5)
Netzwerke und Anwendungen können große Verhaltensunterschiede aufweisen. In einigen extremen Fällen können Anwendungen viele kurzlebige Verbindungen generieren. Dies kann dazu führen, dass conntrack (eine Kernkomponente des Linux-Netzwerkstapels) nicht mehr über genügend Speicher verfügt. Um diese Art von Anwendungen unter Linux auszuführen, mussten Sie traditionell Conntrack manuell konfigurieren oder deaktivieren oder iptables-Regeln schreiben, um Conntrack zu umgehen. Die nicht verfolgte Richtlinie in Calico ist eine einfachere und effizientere Option, wenn Sie Verbindungen so schnell wie möglich verarbeiten möchten. Zum Beispiel, wenn Sie massiv verwenden oder als zusätzliche Schutzmaßnahme gegen .
Lesen Sie dies (oder ) für weitere Informationen, einschließlich Leistungstests mit nicht verfolgten Richtlinien.
Wenn Sie die Option „doNotTrack: true“ in Calico globalNetworkPolicy festlegen, wird sie zu einer **nicht verfolgten** Richtlinie und wird sehr früh in der Linux-Paketverarbeitungspipeline angewendet. Im obigen Diagramm werden nicht verfolgte Richtlinien in den PREROUTING- und OUTPUT-Ketten in der Rohtabelle angewendet, bevor die Verbindungsverfolgung (conntrack) gestartet wird. Wenn ein Paket von der Nicht-Tracking-Richtlinie zugelassen wird, wird es markiert, um die Verbindungsverfolgung für dieses Paket zu deaktivieren. Das heisst:
- Die nicht verfolgte Richtlinie wird pro Paket angewendet. Es gibt kein Konzept der Verbindung (oder des Flusses). Fehlende Verbindungen haben mehrere wichtige Konsequenzen:
- Wenn Sie sowohl Anforderungs- als auch Antwortverkehr zulassen möchten, benötigen Sie eine Regel für eingehenden und ausgehenden Datenverkehr (da Calico normalerweise Conntrack verwendet, um Antwortverkehr als zulässig zu markieren).
- Die nicht verfolgte Richtlinie funktioniert nicht für Kubernetes-Workloads (Pods), da es in diesem Fall keine Möglichkeit gibt, die ausgehende Verbindung vom Pod zu verfolgen.
- NAT funktioniert bei nicht verfolgten Paketen nicht korrekt (da der Kernel die NAT-Zuordnung in conntrack speichert).
- Beim Durchlaufen der „Alle zulassen“-Regel in der Untracked-Richtlinie werden alle Pakete als nicht verfolgt markiert. Das ist fast immer nicht das, was Sie wollen, daher ist es wichtig, bei den Paketen, die von nicht verfolgten Richtlinien zugelassen werden, sehr selektiv vorzugehen (und den Großteil des Datenverkehrs durch normal verfolgte Richtlinien passieren zu lassen).
- Nicht verfolgte Richtlinien werden ganz am Anfang der Paketverarbeitungspipeline angewendet. Dies ist beim Erstellen von Calico-Richtlinien sehr wichtig zu verstehen. Sie können eine Pod-Richtlinie mit order:1 und eine nicht verfolgte Richtlinie mit order:1000 haben. Es wird keine Rolle spielen. Die Richtlinie „Untracked“ wird vor der Richtlinie für den Pod angewendet. Nicht verfolgte Richtlinien respektieren die Ausführungsreihenfolge nur untereinander.
Da einer der Zwecke der doNotTrack-Richtlinie darin besteht, die Richtlinie sehr früh in der Linux-Paketverarbeitungspipeline durchzusetzen, schreibt Calico die Angabe der Option „applyOnForward“ bei der Verwendung von doNotTrack vor. Beachten Sie anhand des Paketverarbeitungsdiagramms, dass die untracked(5)-Richtlinie vor allen Routing-Entscheidungen angewendet wird. Der Datenverkehr kann an den Hostprozess weitergeleitet oder an einen Pod oder einen anderen Knoten weitergeleitet werden.
Ergebnisse
Wir haben uns die verschiedenen Richtlinienoptionen (Host-Endpunkt, ApplyOnForward, preDNAT und Untracked) in Calico und ihre Anwendung entlang des Paketverarbeitungspfads angesehen. Das Verständnis ihrer Funktionsweise hilft bei der Entwicklung wirksamer und sicherer Richtlinien. Mit Calico können Sie eine globale Netzwerkrichtlinie verwenden, die für ein Label (eine Gruppe von Knoten und Pods) gilt, und Richtlinien mit verschiedenen Parametern anwenden. Dadurch können Sicherheits- und Netzwerkdesign-Experten „alles“ (Endpunkttypen) bequem auf einmal schützen, indem sie mit Calico-Richtlinien eine einzige Richtliniensprache verwenden.
Danksagung: Ich möchte mich bedanken и für ihre Bewertung und wertvollen Informationen.
Source: habr.com