Das Calico-Netzwerk-Plugin bietet eine breite Palette von Netzwerkrichtlinien mit einer einheitlichen Syntax zum Schutz von Hosts auf Hardware, virtuellen Maschinen und Pods. Diese Richtlinien können innerhalb von Namespaces oder als globale Netzwerkrichtlinien angewendet werden, die auf (zum Schutz von Anwendungen, die direkt auf dem Host laufen – der Host kann ein physischer Server oder eine virtuelle Maschine sein) oder auf (zum Schutz von Anwendungen, die in Containern oder virtuellen Maschinen, die auf dem Host gehostet sind, laufen). Calico-Richtlinien ermöglichen die Implementierung von Sicherheitsmaßnahmen für verschiedene Paketpfade mit Optionen wie preDNAT, unraracked und applyOnForward. Ein Verständnis dafür, wie diese Optionen funktionieren, kann helfen, die Sicherheit und die Gesamteffizienz des Systems zu verbessern. In diesem Artikel wird das Wesen dieser Calico-Richtlinienoptionen (preDNAT, unraracked und applyOnForward), die auf Host Endpoints angewendet werden, erklärt, wobei der Fokus darauf liegt, was in den Pfaden der Paketverarbeitung (iptable-Ketten) geschieht.
Dieser Artikel setzt voraus, dass Sie ein Grundverständnis für die Funktionsweise von Kubernetes- und Calico-Netzwerkpolitik haben. Wenn nicht, empfehlen wir, es auszuprobieren. und verwenden Sie Calico, bevor Sie diesen Artikel lesen. Wir gehen auch davon aus, dass Sie ein grundlegendes Verständnis der Funktionsweise haben in Linux.
Calico ermöglicht es Ihnen, ein Set von Zugriffsregeln basierend auf Labels (auf Gruppen von Hosts und Workloads/Pods) anzuwenden. Dies ist besonders nützlich, wenn Sie verschiedene Systeme – virtuelle Maschinen, Bare-Metal-Systeme oder Kubernetes-Infrastrukturen – zusammen nutzen. Darüber hinaus können Sie Ihren Cluster (Nodes) mit einem Set von deklarativen Richtlinien schützen und Netzwerkrichtlinien auf den eingehenden Verkehr anwenden (z.B. über NodePorts oder externe IPs).
Auf fundamentaler Ebene verbindet Calico, wenn er einen Pod mit dem Netzwerk verbindet (siehe das Diagramm unten), ihn über eine virtuelle Ethernet-Schnittstelle (veth) mit dem Host. Der vom Pod gesendete Verkehr kommt über diese virtuelle Schnittstelle zum Host und wird so behandelt, als käme er von einer physischen Netzwerkschnittstelle. Standardmäßig bezeichnet Calico diese Schnittstellen als caliXXX. Da der Verkehr über die virtuelle Schnittstelle kommt, wird er durch iptables geleitet, als ob der Pod nur einen Hop entfernt wäre. Daher wird der Verkehr, der vom Pod kommt oder zu ihm geht, aus der Sicht des Hosts weitergeleitet.
Auf dem Kubernetes-Knoten, auf dem Calico läuft, können Sie die virtuelle Schnittstelle (veth) wie folgt mit der Workload verknüpfen. 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: 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 jede Arbeitslast ein veth-Interface erstellt, wie wendet es dann Richtlinien an? Zu diesem Zweck integriert Calico Hooks in verschiedene Ketten des Paketverarbeitungsweges, indem es iptables nutzt.
Das folgende Diagramm zeigt die Ketten, die an der Paketverarbeitung in iptables (oder dem netfilter-Subsystem) beteiligt sind. Wenn ein Paket über das Netzwerkinterface eintrifft, durchläuft es zunächst die PREROUTING-Kette. Anschließend wird eine Routing-Entscheidung getroffen, aufgrund derer das Paket entweder die INPUT-Kette (gerichtet an Host-Prozesse) oder die FORWARD-Kette (gerichtet an ein Pod oder einen anderen Knoten im Netzwerk) durchläuft. Von einem lokalen Prozess aus gelangt das Paket über die OUTPUT-Kette und dann die POSTROUTING-Kette, bevor es über das Kabel gesendet wird.
Beachten Sie, dass ein Pod aus der Perspektive der iptables-Verarbeitung ebenfalls ein externes Objekt (verbunden mit veth) darstellt. Fassen wir zusammen:
- Der weitergeleitete (forwarded) Verkehr (nat, routierbar oder aus / in ein Pod) durchläuft die Ketten PREROUTING — FORWARD — POSTROUTING.
- Der Verkehr zum lokalen Host-Prozess durchläuft die Ketten PREROUTING — INPUT.
- Der Verkehr vom lokalen Host-Prozess durchläuft die Ketten OUTPUT — POSTROUTING.
Calico bietet Optionen für Richtlinien, mit denen Richtlinien für alle Ketten angewendet werden können. Vor diesem Hintergrund werfen wir einen Blick auf die verschiedenen Konfigurationsmöglichkeiten für Richtlinien, die in Calico verfügbar sind. Die Zahlen in der nachstehenden Liste der Optionen entsprechen den Zahlen im obigen Diagramm.
- Workload-Endpunkt (Pod)-Richtlinie
- Host-Endpunkt-Richtlinie
- Option ApplyOnForward
- PreDNAT-Richtlinie
- Untracked-Richtlinie
Lassen Sie uns zunächst betrachten, wie Richtlinien auf Workload-Endpunkte (Kubernetes-Pods oder OpenStack-VMs) angewendet werden, und dann die Richtlinienoptionen für Host-Endpunkte untersuchen.
Workload-Endpunkte
Workload-Endpunkt-Richtlinie (1)
Diese Option dient dem Schutz Ihrer Kubernetes-Pods. Calico unterstützt die Verwendung von Kubernetes NetworkPolicy, bietet jedoch auch zusätzliche Richtlinien — Calico NetworkPolicy und GlobalNetworkPolicy. Calico erstellt eine Kette für jeden Pod (Workload) und hookt in die INPUT- und OUTPUT-Ketten für Workloads in die Filtertabelle der FORWARD-Kette.
Host-Endpunkte
Host-Endpunkt-Richtlinie (2)
Neben der CNI (Container-Netzwerkschnittstelle) bieten die Calico-Richtlinien die Möglichkeit, den Host direkt zu schützen. In Calico können Sie einen Host-Endpunkt erstellen, indem Sie eine Kombination aus Host-Schnittstelle und, falls erforderlich, Portnummern festlegen. Die Anwendung dieser Richtlinien auf diese Entität erfolgt über Tabellenfilter in den INPUT- und OUTPUT-Ketten. Wie aus dem Diagramm ersichtlich ist, werden sie auf lokale Prozesse auf dem Knoten/Host angewendet. Das heißt, wenn Sie eine Richtlinie erstellt haben, die auf den Host-Endpunkt angewendet wird, hat dies keinen Einfluss auf den Verkehr, der zu/von Ihren Pods fließt. Aber sie sorgt für eine einheitliche Schnittstelle/Syntax zur Blockierung des Verkehrs für Ihren Host und die Pods mithilfe von Calico-Richtlinien. Das vereinfacht den Prozess der Richtlinienverwaltung für heterogene Netzwerke erheblich. Die Konfiguration von Host-Endpunkt-Richtlinien zur Verstärkung des Schutzes des Clusters ist ein weiterer wichtiger Anwendungsfall.
ApplyOnForward Policy (3)
Die Option ApplyOnForward ist in der Calico-Globalnetzwerkpolitik verfügbar, um die Anwendung von Richtlinien auf allen Datenverkehr zu ermöglichen, der durch den Host-Endpunkt fließt, einschließlich des Datenverkehrs, der vom Host weitergeleitet wird. Dieser Datenverkehr umfasst den an einen lokalen Pod oder irgendwo sonst im Netzwerk weitergeleiteten Datenverkehr. Calico erfordert, dass diese Option für Richtlinien, die PreDNAT und untracked verwenden, aktiviert ist. Siehe die folgenden Abschnitte. Darüber hinaus kann ApplyOnForward verwendet werden, um den Host-Verkehr in Fällen zu verfolgen, in denen ein virtueller Router oder Software-NAT verwendet wird.
Beachten Sie, dass Sie die gleiche Netzwerkpolitik sowohl für Host-Prozesse als auch für Pods anwenden müssen, ohne die Option ApplyOnForward nutzen zu müssen. Es reicht aus, ein Label für den entsprechenden Hostendpoint und den Workload-Endpunkt (Pod) zu erstellen. Calico ist intelligent genug, um die Richtlinie basierend auf Labels anzuwenden, unabhängig vom Typ des Endpunkts (Hostendpoint oder Workload).
PreDNAT-Richtlinie (4)
In Kubernetes können die Ports der Service-Entität über NodePorts nach außen geleitet werden oder, optional (bei Verwendung von Calico), indem sie über die Optionen Cluster IPs oder External IPs deklariert werden. Kube-proxy balanciert den eingehenden Datenverkehr, der mit dem Service verknüpft ist, auf die Pods des entsprechenden Services mittels DNAT (Destination Network Address Translation). Vor diesem Hintergrund, wie können Sie Richtlinien für den Verkehr, der über NodePorts eingeht, anwenden? Damit diese Richtlinien angewendet werden, bevor der Verkehr durch DNAT verarbeitet wird (das die Zuordnung von Host:Port und dem entsprechenden Service darstellt), bietet Calico ein Parameter für die globalNetworkPolicy mit dem Namen „preDNAT: true“ an.
Wenn pre-DNAT aktiviert ist, werden diese Richtlinien in (4) auf dem Diagramm — in der mangle-Kette PREROUTING — direkt vor DNAT umgesetzt. Die normale Reihenfolge der Richtlinien (order) wird dabei nicht eingehalten, da die Anwendung dieser Richtlinien much früher im Verarbeitungsweg des Datenverkehrs erfolgt. Dennoch folgen die preDNAT-Richtlinien der Reihenfolge der Anwendung (order) untereinander.
Beim Erstellen von Richtlinien mit pre-DNAT ist es wichtig, auf den Verkehr zu achten, den Sie verarbeiten möchten, und die meisten Verbindungen abzulehnen. Verkehr, der in der pre-DNAT-Richtlinie als 'erlaubt' gekennzeichnet ist, wird nicht mehr durch die hostendpoint-Richtlinie überprüft, während der Verkehr, der bei der Prüfung der pre-DNAT-Richtlinie fehlschlägt, weiterhin den restlichen Ketten folgt.
Calico hat die Aktivierung der Option applyOnForward bei Verwendung von preDNAT zur Pflicht gemacht, da das Ziel des Verkehrs definitionsgemäß noch nicht ausgewählt ist. Der Verkehr kann an einen Host-Prozess gesendet oder an ein Pod oder einen anderen Knoten umgeleitet werden.
Unverfolgte Richtlinie (5)
Netzwerke und Anwendungen können große Unterschiede im Verhalten aufweisen. In einigen extremen Fällen können Anwendungen eine große Anzahl kurzer Verbindungen erzeugen. Dies kann zu einem Speichermangel bei conntrack (dem Hauptbestandteil des Linux-Netzstacks) führen. Traditionell müssen Sie unter Linux, um Anwendungen dieses Typs zu starten, conntrack manuell konfigurieren oder deaktivieren oder iptables-Regeln schreiben, um conntrack zu umgehen. Die untracked policy in Calico ist eine einfachere und effektivere Option, wenn Sie Verbindungen so schnell wie möglich verarbeiten möchten. Zum Beispiel, wenn Sie ein massives oder als zusätzliche Schutzmaßnahme gegen .
Lesen Sie diesen (oder ) für weitere Informationen, einschließlich Leistungstests bei Verwendung der untracked policy.
Wenn Sie die Option „doNotTrack: true“ in der Calico globalNetworkPolicy festlegen, wird sie zu einer **nicht nachverfolgbaren** Richtlinie und wird in der frühesten Phase des Linux-Paketverarbeitungskanals angewendet. Betrachtet man das obige Diagramm, so werden nicht nachverfolgte Richtlinien in den PREROUTING- und OUTPUT-Ketten der RAW-Tabelle angewendet, bevor die Verbindungsverfolgung (conntrack) gestartet wird. Wenn ein Paket von der nicht nachverfolgten Richtlinie zugelassen wird, wird es so markiert, dass die Verbindungsverfolgung für dieses Paket deaktiviert wird. Das bedeutet:
- Die nicht nachverfolgte Richtlinie wird für jedes Paket angewendet. Es gibt kein Konzept von Verbindungen (oder Flüssen). Das Fehlen von Verbindungen hat mehrere wichtige Konsequenzen:
- Wenn Sie sowohl den Anforderungsverkehr als auch den Antwortverkehr zulassen möchten, benötigen Sie sowohl eine Regel für eingehenden als auch für outgoing Verkehr (da Calico normalerweise conntrack verwendet, um den Antwortverkehr als zulässig zu kennzeichnen).
- Die nicht nachverfolgte Richtlinie funktioniert nicht für Kubernetes-Workloads (Pods), da es in diesem Fall keinen Weg gibt, eine ausgehende Verbindung aus einem Pod nachzuverfolgen.
- NAT funktioniert nicht korrekt mit nicht nachverfolgbaren Paketen (da der Kernel die NAT-Zuordnung in conntrack speichert).
- Wenn Sie durch die Regel „alle zulassen“ in der untracked-Policy gehen, werden alle Pakete als nicht verfolgt markiert. Dies ist fast immer nicht das, was Sie brauchen, daher ist es wichtig, sehr wählerisch bei den Paketen zu sein, die durch untracked-Policies erlaubt werden (und mehr Verkehr durch die regulären verfolgten Policies fließen zu lassen).
- Untracked-Policies werden ganz am Anfang der Paketverarbeitungspipeline angewendet. Das ist sehr wichtig zu verstehen, wenn Sie Calico-Policies erstellen. Sie können eine Policy für ein Pod mit order:1 und eine untracked-Policy mit order:1000 haben. Das wird unwichtig sein. Die untracked-Policy wird vor der Policy für das Pod angewendet. Untracked-Policies beachten die Ausführungsreihenfolge nur zwischen sich selbst.
Da eines der Ziele der doNotTrack-Policy darin besteht, die Politik so früh wie möglich in der Paketverarbeitungspipeline von Linux durchzusetzen, macht Calico es erforderlich, die Option applyOnForward bei der Verwendung von doNotTrack anzugeben. Wenn Sie auf das Diagramm der Paketverarbeitung achten, beachten Sie, dass die untracked-Policy (5) vor jeglichen Routingentscheidungen angewendet wird. Der Verkehr kann an einen Hostprozess geleitet werden oder er kann an ein Pod oder einen anderen Knoten umgeleitet werden.
Ergebnisse
Wir haben verschiedene Optionen für Netzwerkrichtlinien (Host Endpoint, ApplyOnForward, preDNAT und Untracked) in Calico betrachtet und wie sie beim Paketverarbeitungsprozess angewendet werden. Das Verständnis ihrer Funktionsweise hilft bei der Entwicklung effektiver und sicherer Richtlinien. Mit Calico können Sie eine globale Netzwerkrichtlinie verwenden, die auf Labels (Gruppen von Nodes und Pods) angewendet wird und Richtlinien mit verschiedenen Parametern anwendet. Dies ermöglicht es Sicherheits- und Netzwerkspezialisten, gleichsam alles (Endpoint-Typen) bequem zu schützen, indem sie eine einheitliche Sprache für Richtlinien mit Calico-Richtlinien nutzen.
Dank: Ich möchte mich bedanken bei und für ihre Überprüfung und die wertvollen Informationen.
Quelle: habr.com
