Das Netzwerkplugin Calico bietet eine umfassende Sammlung von Netzwerkrichtlinien mit einheitlicher Syntax zum Schutz von Hosts auf Hardware, virtuellen Maschinen und Pods. Diese Richtlinien können innerhalb eines Namespaces angewendet oder als globale Netzwerkrichtlinien eingesetzt werden, die auf (zum Schutz von Anwendungen, die direkt auf dem Host laufen – wobei der Host entweder ein physischer Server oder eine virtuelle Maschine sein kann) oder auf (zum Schutz von Anwendungen, die in Containern oder virtuellen Maschinen laufen, die auf dem Host gehostet werden). Die Calico-Richtlinien ermöglichen die Anwendung von Sicherheitsmaßnahmen für verschiedene Paketpfade mit Optionen wie preDNAT, unraracked und applyOnForward. Das Verständnis, wie diese Optionen funktionieren, kann helfen, die Sicherheit und die Leistung des Gesamtsystems zu verbessern. In diesem Artikel wird erklärt, worum es bei diesen Parametern der Calico-Richtlinien (preDNAT, unraracked und applyOnForward) geht, die auf Host-Endpunkte angewendet werden, mit einem Fokus darauf, was in den Paketverarbeitungswegen (iptables-Ketten) passiert.
Dieser Artikel setzt voraus, dass Sie ein Grundverständnis der Funktionsweise von Kubernetes- und Calico-Netzwerkrichtlinien haben. Wenn nicht, empfehlen wir, den und mit Calico auszuprobieren, 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, eine Reihe von Zugriffsregeln auf Basis von Labels (für Gruppen von Hosts und Workloads/Pods) anzuwenden. Dies ist besonders nützlich, wenn Sie verschiedene Systeme – virtuelle Maschinen, physische Server oder Kubernetes-Infrastruktur – zusammen nutzen. Außerdem können Sie Ihren Cluster (Knoten) mit einer Reihe von deklarativen Richtlinien schützen und Netzwerkrichtlinien auf eingehenden Datenverkehr anwenden (zum Beispiel über NodePorts oder externe IPs).
Auf fundamentaler Ebene, wenn Calico ein Pod mit dem Netzwerk verbindet (siehe das Diagramm unten), verbindet es ihn über ein virtuelles Ethernet-Interface (veth) mit dem Host. Der vom Pod gesendete Datenverkehr kommt über dieses virtuelle Interface auf den Host und wird so behandelt, als stamme er von einem physischen Netzwerk-Interface. Standardmäßig nennt Calico diese Interfaces caliXXX. Da der Datenverkehr über das virtuelle Interface kommt, durchläuft er iptables, als ob der Pod einen Hop entfernt wäre. Daher wird, wenn der Datenverkehr vom Pod ankommt oder ausgeht, dieser aus der Sicht des Hosts weitergeleitet (forwarded).
Auf dem Kubernetes-Knoten, auf dem Calico läuft, können Sie das virtuelle Interface (veth) mit der Arbeitslast wie folgt zuordnen. Im unten stehenden Beispiel können Sie sehen, dass veth#10 (calic1cbf1ca0f8) mit cnx-manager-* im Namespace calico-monitoring 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 die Richtlinien an? Dazu erstellt Calico Hooks in verschiedene Ketten des Paketverarbeitungswegs unter Verwendung von iptables.
Im untenstehenden Diagramm sind die Ketten dargestellt, die an der Paketverarbeitung in iptables (oder der netfilter-Subsystem) beteiligt sind. Wenn ein Paket über das Netzwerkinterface eintrifft, durchläuft es zunächst die Kette PREROUTING. Anschließend wird eine Routing-Entscheidung getroffen, und basierend darauf durchläuft das Paket entweder INPUT (gerichtet an die Prozesse des Hosts) oder FORWARD (gerichtet auf den Pod oder einen anderen Knoten im Netzwerk). Aus dem lokalen Prozess durchläuft das Paket die Kette OUTPUT und dann POSTROUTING, bevor es über das Kabel gesendet wird.
Bitte beachten Sie, dass der Pod auch ein externes Objekt (verbunden mit veth) aus der Sicht von iptables ist. Zusammenfassend:
- Der weitergeleitete (forwarded) Datenverkehr (nat, geroutet oder in / aus dem Pod) durchläuft die Ketten PREROUTING - FORWARD - POSTROUTING.
- Der Datenverkehr, der an den lokalen Host-Prozess geht, durchläuft die Kette PREROUTING - INPUT.
- Der Datenverkehr vom lokalen Host-Prozess durchläuft die Kette OUTPUT - POSTROUTING.
Calico bietet Optionen für Richtlinien, mit denen Richtlinien für alle Ketten angewendet werden können. In diesem Sinne betrachten wir die verschiedenen Anpassungsoptionen für die in Calico verfügbaren Richtlinien. Die Zahlen in der Liste der Optionen unten entsprechen den Zahlen in der 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 (Pods von Kubernetes oder OpenStack VMs) angewendet werden, und dann die Optionen für Richtlinien für Host-Endpunkte untersuchen.
Workload-Endpunkte
Workload-Endpunkt-Richtlinie (1)
Diese Option dient zum Schutz Ihrer Kubernetes-Pods. In Calico wird die Zusammenarbeit mit Kubernetes NetworkPolicy unterstützt, aber zusätzlich werden weitere Richtlinien bereitgestellt — Calico NetworkPolicy und GlobalNetworkPolicy. Calico erstellt eine Kette für jeden Pod (Workload) und Haken in die INPUT- und OUTPUT-Ketten für Workload zur Filtertabelle der FORWARD-Kette.
Host-Endpunkte
Host-Endpunkt-Richtlinie (2)
Neben CNI (Container-Netzwerkschnittstelle) bieten die Richtlinien von Calico 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 Anwendung von Richtlinien für dieses Element erfolgt über die Filtertabelle in den INPUT- und OUTPUT-Ketten. Wie aus dem Diagramm ersichtlich, (2) 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, wird sie den Verkehr, der zu/von Ihren Pods fließt, nicht beeinträchtigen. Doch sie sorgt für eine einheitliche Schnittstelle/Syntax zur Blockierung des Verkehrs für Ihren Host und Pods mithilfe der Calico-Richtlinien. Dies vereinfacht den Managementprozess von Richtlinien für heterogene Netzwerke erheblich. Die Konfiguration von Host-Endpunkt-Richtlinien zur Verstärkung des Cluster-Schutzes ist ein weiterer wichtiger Anwendungsfall.
ApplyOnForward-Richtlinie (3)
Die Option ApplyOnForward ist in der Calico-Global-Network-Richtlinie verfügbar, um die Anwendung von Richtlinien auf den gesamten Verkehr zu ermöglichen, der durch den Host-Endpunkt fließt, einschließlich des Verkehrs, der vom Host weitergeleitet wird. Dieser Verkehr umfasst den an einen lokalen Pod oder anderswo im Netzwerk weitergeleiteten Verkehr. Calico erfordert, dass diese Option für Richtlinien verwendet wird, die PreDNAT und untracked verwenden, siehe die nächsten Abschnitte. Darüber hinaus kann ApplyOnForward verwendet werden, um den Verkehr des Hosts in Fällen zu verfolgen, in denen ein virtueller Router oder Software-NAT verwendet wird.
Bitte beachten Sie, dass Sie die gleiche Netzwerkpolitik sowohl für Host-Prozesse als auch für Pods anwenden können, ohne die Option ApplyOnForward verwenden zu müssen. Es reicht aus, ein Label für die benötigten Hostendpunkte und Arbeitslastendpunkte (Pod) zu erstellen. Calico ist intelligent genug, um die Politik basierend auf Labels anzuwenden, unabhängig vom Typ des Endpunkts (Hostendpunkt oder Arbeitslast).
PreDNAT-Politik (4)
In Kubernetes können die Ports der Service-Entität nach außen über die Option NodePorts oder optional (bei Verwendung von Calico) über deren Erklärung via Cluster-IPs oder External-IPs weitergeleitet werden. Kube-Proxy verteilt den eingehenden Traffic, der an den Service gebunden ist, auf die Pods des entsprechenden Services unter Verwendung von DNAT. Vor diesem Hintergrund, wie wenden Sie die Politiken auf den Traffic an, der über NodePorts kommt? Damit diese Politiken angewendet werden, bevor der Traffic mit DNAT verarbeitet wird (das eine Zuordnung von Host:Port zu dem entsprechenden Service darstellt), stellt Calico einen Parameter für die globalNetworkPolicy bereit, der als „preDNAT: true“ bezeichnet wird.
Wenn pre-DNAT aktiviert ist, werden diese Politiken wie in (4) in der Diagaramm-Tabelle der Mangle-Kette PREROUTING umgesetzt – direkt vor DNAT. Die übliche Reihenfolge der Politiken (order) wird hier nicht eingehalten, da die Anwendung dieser Politiken viel früher im Verarbeitungsweg des Traffics erfolgt. Dennoch halten die preDNAT-Politiken die Anwendungsreihenfolge (order) untereinander ein.
Bei der Erstellung von Politiken mit pre-DNAT ist es wichtig, auf den Traffic, den Sie verarbeiten möchten, zu achten und die meisten abzulehnen. Der als 'allow' in der pre-DNAT-Politik gekennzeichnete Traffic wird nicht mehr von der Hostendpunkt-Politik überprüft, während der Traffic, der die pre-DNAT-Politik nicht besteht, seinen Weg durch die anderen Ketten fortsetzen wird.
Calico hat die Aktivierung der Option applyOnForward zur Verwendung von preDNAT zwingend erforderlich gemacht, da der Zielort des Traffics per Definition noch nicht ausgewählt ist. Der Traffic kann auf einen Host-Prozess gerichtet sein, oder er kann auf einen Pod oder einen anderen Knoten umgeleitet werden.
Untracked Policy (5)
Netzwerke und Anwendungen können sich im Verhalten stark unterscheiden. In einigen extremen Fällen können Anwendungen eine Vielzahl kurzfristiger Verbindungen generieren. Dies kann zu unzureichendem Speicher bei conntrack (dem Hauptbestandteil des Linux-Netzstacks) führen. Traditionell müssen Sie zur Ausführung solcher Anwendungen unter Linux conntrack manuell konfigurieren oder deaktivieren oder iptables-Regeln erstellen, 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. Wenn Sie beispielsweise einen massiven oder als zusätzliche Schutzmaßnahme gegen .
Lesen Sie diesen (oder ) für weitere Informationen, einschließlich Leistungstests bei der Verwendung der Untracked-Policy.
Wenn Sie die Option „doNotTrack: true“ in Calico globalNetworkPolicy festlegen, wird sie zur **unverfolgten** Richtlinie und wird im frühesten Stadium der Paketverarbeitungspipeline von Linux angewendet. Wenn Sie sich das obenstehende Diagramm ansehen, werden untracked-Richtlinien in den PREROUTING- und OUTPUT-Ketten der Raw-Tabelle angewendet, bevor das Verbindungsverfolgung (conntrack) gestartet wird. Wenn ein Paket von der Untracked-Richtlinie erlaubt wird, wird es markiert, um die Verfolgung der Verbindung für dieses Paket zu deaktivieren. Das bedeutet:
- Die Untracked-Policy wird für jedes Paket angewendet. Es gibt kein Konzept einer Verbindung (oder eines Flusses). Das Fehlen von Verbindungen hat mehrere wichtige Folgen:
- Wenn Sie sowohl Anforderungs- als auch Antwortverkehr zulassen möchten, benötigen Sie eine Regel sowohl für eingehenden als auch für ausgehenden Verkehr (da Calico normalerweise conntrack verwendet, um den Antwortverkehr als erlaubt zu markieren).
- Die Untracked-Policy funktioniert nicht für Kubernetes-Workloads (Pods), da es in diesem Fall keine Möglichkeit gibt, die ausgehende Verbindung aus einem Pod zu verfolgen.
- NAT funktioniert nicht korrekt mit unverfolgten Paketen (da der Kernel die NAT-Zuordnung in conntrack speichert).
- Beim Durchlaufen der Regel „alles erlauben“ in der Untracked-Policy werden alle Pakete als unverfolgt markiert. Das ist fast immer nicht das, was Sie benötigen, daher ist es wichtig, bei den als untracked-Politiken erlaubten Paketen sehr wählerisch zu sein (und den Großteil des Verkehrs durch die normalen, verfolgten Politiken zu lassen).
- Untracked-Richtlinien werden ganz zu Beginn des Paketverarbeitungsprozesses angewendet. Es ist sehr wichtig, dies beim Erstellen von Calico-Richtlinien zu verstehen. Sie können eine Richtlinie für einen Pod mit order:1 und eine untracked-Richtlinie mit order:1000 haben. Das spielt keine Rolle. Die untracked-Richtlinie wird vor der Richtlinie für den Pod angewendet. Untracked-Richtlinien beachten die Ausführungsreihenfolge nur untereinander.
Da eines der Ziele der doNotTrack-Richtlinie die Durchsetzung dieser Richtlinie in einem sehr frühen Stadium des Paketverarbeitungsprozesses in Linux ist, macht Calico die Angabe der Option applyOnForward beim Einsatz von doNotTrack zwingend erforderlich. Wenn Sie sich das Diagramm der Paketverarbeitung ansehen, beachten Sie, dass die untracked-Richtlinie (5) vor allen Routingentscheidungen angewendet wird. Der Datenverkehr kann an einen Host-Prozess weitergeleitet werden, oder er kann an einen Pod oder einen anderen Knoten umgeleitet werden.
Ergebnisse
Wir haben verschiedene Richtlinienoptionen (Host-Endpunkt, ApplyOnForward, preDNAT und Untracked) in Calico betrachtet und wie sie im Paketverarbeitungsweg angewendet werden. Das Verständnis ihrer Funktionsweise hilft bei der Entwicklung effektiver und sicherer Richtlinien. Mit Calico können Sie eine globale Netzwerkpolitik verwenden, die auf ein Label (eine Gruppe von Knoten und Pods) angewendet wird, sowie Richtlinien mit verschiedenen Parametern anwenden. Dies ermöglicht es Sicherheits- und Netzwerkspezialisten, sofort alles (Arten von Endpunkten) zu schützen, indem sie eine einheitliche Sprache für Politiken mit Calico verwenden.
Dank: Ich möchte mich bedanken bei und für ihre Überprüfung und wertvolle Informationen.
Quelle: habr.com
