Get best of the week

Grundlegendes zu Netzwerkrichtlinien mit Calico



Das Calico Network Plugin bietet eine Vielzahl von Netzwerkrichtlinien mit einer einheitlichen Syntax zum Schutz von Hosts auf Hardware, virtuellen Maschinen und Pods. Diese Richtlinien können innerhalb des Namespace angewendet werden oder globale Netzwerkrichtlinien sein, die für den Host-Endpunkt gelten (zum Schutz von Anwendungen, die direkt auf dem Host ausgeführt werden - der Server oder die virtuelle Maschine kann direkt der Host sein) oder zum Workload-Endpunkt(zum Schutz von Anwendungen, die in gehosteten Containern oder virtuellen Maschinen ausgeführt werden). Mit Calico-Richtlinien können Sie Sicherheitsmaßnahmen auf verschiedene Punkte im Paketpfad anwenden, indem Sie Parameter wie preDNAT, untracked und applyOnForward verwenden. Wenn Sie wissen, wie diese Optionen funktionieren, können Sie die Sicherheit und Leistung des gesamten Systems verbessern. In diesem Artikel wird das Wesentliche dieser Calico-Richtlinieneinstellungen (preDNAT, unraracked und applyOnForward) erläutert, die auf Host-Endpunkte angewendet werden, wobei der Schwerpunkt auf den Vorgängen in Paketverarbeitungspfaden (iptabels-Ketten) liegt.

In diesem Artikel wird davon ausgegangen, dass Sie wissen, wie die Netzwerkrichtlinien von Kubernetes und Calico funktionieren. Wenn nicht, empfehlen wir Ihnen , die versuchen , grundlegende Netzwerkrichtlinien Tutorial und Hostschutz Tutorial Calico verwenden , bevor Sie diesen Artikel lesen. Wir erwarten auch, dass Sie ein grundlegendes Verständnis von iptables unter Linux haben. Globale Netzwerkrichtlinie von

CalicoMit dieser Option können Sie eine Reihe von Zugriffsregeln für Labels anwenden (auf Hostgruppen und Workloads / Pods). Dies ist sehr nützlich, wenn Sie heterogene Systeme zusammen verwenden - virtuelle Maschinen, ein System direkt auf der Hardware oder die 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-Dienst oder externe IPs).

Wenn Calico einen Pod mit einem Netzwerk verbindet (siehe Abbildung unten), verbindet er ihn grundsätzlich über eine virtuelle Ethernet-Schnittstelle (veth) mit einem Host. Der vom Pod gesendete Datenverkehr kommt über diese virtuelle Schnittstelle beim Host an und wird so verarbeitet, als stamme er von einer physischen Netzwerkschnittstelle. Standardmäßig nennt Calico diese Schnittstellen caliXXX. Da der Datenverkehr über die virtuelle Schnittstelle erfolgt, durchläuft er iptables, als ob sich der Pod in der Entfernung eines Hops befindet. Wenn also Verkehr vom Pod kommt / kommt, wird er aus Sicht des Hosts weitergeleitet.

Auf dem Kubernetes-Knoten, auf dem Calico ausgeführt wird, können Sie die virtuelle Schnittstelle (veth) wie folgt der Arbeitslast zuordnen. Im folgenden Beispiel sehen Sie, dass veth # 10 (calic1cbf1ca0f8) im Calico-Monitoring-Namespace mit cnx-manager- * 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
...



Wie werden Richtlinien angewendet, da Calico für jede Arbeitslast eine veth-Schnittstelle erstellt? Zu diesem Zweck erstellt Calico mithilfe von iptables Hooks in verschiedenen Ketten des Paketverarbeitungspfads.

Das folgende Diagramm zeigt die Ketten, die an der Verarbeitung von Paketen in iptables (oder dem Netfilter-Subsystem) beteiligt sind. Wenn ein Paket über eine Netzwerkschnittstelle ankommt, durchläuft es zuerst die PREROUTING-Kette. Dann wird eine Routing-Entscheidung getroffen, und basierend darauf durchläuft das Paket entweder INPUT (an Host-Prozesse gerichtet) oder FORWARD (an Pod oder einen anderen Knoten im Netzwerk gerichtet). Vom lokalen Prozess durchläuft das Paket die OUTPUT-Kette und dann POSTROUTING, bevor es über das Kabel gesendet wird.

Beachten Sie, dass pod auch ein externes Objekt (mit veth verbunden) ist, was die Handhabung von iptables betrifft. Zusammenfassen:

  • Der weitergeleitete Verkehr (nat, zum / vom Pod geleitet) wird durch die Ketten PREROUTING - FORWARD - POSTROUTING geleitet.
  • Der Datenverkehr zum lokalen Hostprozess durchläuft die PREROUTING - INPUT-Kette.
  • Der Datenverkehr vom lokalen Hostprozess durchläuft die Kette OUTPUT - POSTROUTING.



Calico bietet Richtlinienoptionen zum Anwenden von Richtlinien auf alle Ketten. Schauen wir uns vor diesem Hintergrund die verschiedenen in Calico verfügbaren Richtlinieneinstellungen an. Die Zahlen in der Optionsliste unten entsprechen den Zahlen im obigen Diagramm.

  1. Workload-Endpunktrichtlinie (Pod)
  2. Host-Endpunktrichtlinie
  3. ApplyOnForward Option
  4. PreDNAT-Richtlinie
  5. Nicht verfolgte Richtlinie

Lassen Sie uns zunächst untersuchen, wie Richtlinien für Workload-Endpunkte (Kubernetes oder OpenStack VMs-Pods) gelten, und anschließend die Richtlinienoptionen für Host-Endpunkte.

Workload-Endpunkte


Workload-Endpunktrichtlinie (1)


Dies ist eine Option zum Schutz Ihrer Kubernetes-Pods. Calico unterstützt die Arbeit mit Kubernetes NetworkPolicy, bietet jedoch auch zusätzliche Richtlinien - Calico NetworkPolicy und GlobalNetworkPolicy. Calico erstellt eine Kette für jeden Pod (Workload) und hakt die INPUT- und OUTPUT-Ketten für die Workload in die Filtertabelle der FORWARD-Kette ein.

Host-Endpunkte


Host-Endpunktrichtlinie (2)


Zusätzlich zu CNI (Container Network Interface) bieten 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 ggf. Port-Nummern angeben. Die Anwendung von Richtlinien für diese Entität wird mithilfe der Filtertabelle in den Ketten INPUT und OUTPUT erreicht. Wie aus dem Diagramm ersichtlich ist, (2) werden sie auf lokale Prozesse auf dem Knoten / Host angewendet. Das heißt, wenn Sie eine Richtlinie erstellt haben, die für den Host-Endpunkt gilt, hat dies keine Auswirkungen auf den Datenverkehr zu / von Ihren Pods. 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. Das Konfigurieren von Host-Endpunktrichtlinien zur Verbesserung des Clusterschutzes ist ein weiterer wichtiger Anwendungsfall.

ApplyOnForward-Richtlinie (3)


Die Option ApplyOnForward ist in der globalen Netzwerkrichtlinie von Calico verfügbar, damit Richtlinien auf den gesamten Datenverkehr angewendet werden können, der über den Host-Endpunkt geleitet wird, einschließlich des Datenverkehrs, der vom Host weitergeleitet wird. Dieser Datenverkehr umfasst das Senden an einen lokalen Pod oder an eine andere Stelle im Netzwerk. 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 verwendet werden, um den Host-Verkehr zu verfolgen, wenn ein virtueller Router oder Software-NAT verwendet wird.

Beachten Sie, dass Sie die ApplyOnForward-Option nicht verwenden müssen, wenn Sie dieselbe Netzwerkrichtlinie für Hostprozesse und Pods anwenden müssen. Sie müssen lediglich eine Beschriftung für den gewünschten Hostendpunkt und Workload-Endpunkt (Pod) erstellen. Calico ist intelligent genug, um beschriftungsbasierte Richtlinien anzuwenden, unabhängig von der Art des Endpunkts (Hostendpunkt oder Arbeitslast).

PreDNAT-Richtlinie (4)


In Kubernetes können die Ports der Service-Entität mithilfe der Option NodePorts oder optional (bei Verwendung von Calico) nach außen weitergeleitet werden, indem sie über die Optionen Cluster-IPs oder Externe IPs deklariert werden. Kube-Proxy gleicht den an den Dienst gebundenen eingehenden Datenverkehr mithilfe von DNAT an die Pods des entsprechenden Dienstes aus. Wie wenden Sie vor diesem Hintergrund Richtlinien auf Datenverkehr an, der über NodePorts eingeht? Damit diese Richtlinien angewendet werden können, bevor der Datenverkehr von DNAT verarbeitet wird (dies ist eine Zuordnung zwischen Host: Port und dem entsprechenden Dienst), 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 - in der Mangle-Tabelle der PREROUTING-Kette - unmittelbar vor DNAT implementiert. Die übliche Bestellrichtlinie wird hier nicht eingehalten, da die Anwendung dieser Richtlinien auf dem Weg der Datenverkehrsverarbeitung viel früher erfolgt. PreDNAT-Richtlinien berücksichtigen jedoch die Reihenfolge der Anwendung untereinander.

Wenn Sie Richtlinien mit Pre-DNAT erstellen, ist es wichtig, den Datenverkehr zu berücksichtigen, den Sie verarbeiten möchten, und zuzulassen, dass die meisten abgelehnt werden. Der in der Vor-DNAT-Richtlinie als "Zulassen" gekennzeichnete Datenverkehr wird von der Hostendpoint-Richtlinie nicht mehr überprüft, während der Datenverkehr, wenn die Vor-DNAT-Richtlinie fehlschlägt, weiterhin durch den Rest der Ketten fließt.
Calico hat es obligatorisch gemacht, die Option applyOnForward zu aktivieren, wenn preDNAT verwendet wird, da das Ziel des Datenverkehrs per Definition noch nicht ausgewählt wurde. Der Datenverkehr kann an den Host-Prozess geleitet oder an einen Pod oder einen anderen Knoten umgeleitet werden.

Nicht verfolgte Richtlinie (5)


Netzwerke und Anwendungen können große Verhaltensunterschiede aufweisen. In einigen extremen Fällen können Anwendungen viele kurzfristige Verbindungen erzeugen. Dies kann zu einem Speichermangel für conntrack (die Hauptkomponente des Linux-Netzwerkstapels) führen. Um diese Art von Anwendung unter Linux auszuführen, müssen Sie conntrack traditionell manuell konfigurieren oder deaktivieren oder iptables-Regeln schreiben, um conntrack zu umgehen. Nicht verfolgte Richtlinien in Calico sind eine einfachere und effizientere Option, wenn Sie Verbindungen so schnell wie möglich verarbeiten möchten. Zum Beispiel, wenn Sie massiven Memcache verwenden oder als zusätzliche Schutzmaßnahme gegen DDOS .

Lesen Sie diesen Blog-Beitrag (oder unsere Übersetzung) für weitere Informationen, einschließlich Leistungstests unter Verwendung der nicht verfolgten Richtlinie.

Wenn Sie die Option "doNotTrack: true" auf Calico globalNetworkPolicy setzen, wird sie zu einer ** nicht verfolgten ** Richtlinie und wird in einem sehr frühen Stadium der Linux-Paketverarbeitungspipeline angewendet. Wenn Sie sich das obige Diagramm ansehen, werden nicht verfolgte Richtlinien in den Ketten PREROUTING und OUTPUT in der Rohtabelle angewendet, bevor die Verbindungsverfolgung (conntrack) gestartet wird. Wenn ein Paket von einer nicht verfolgten Richtlinie zugelassen wird, wird es markiert, um die Verbindungsverfolgung für dieses Paket zu deaktivieren. Das heisst:

  • Für jedes Paket wird eine nicht verfolgte Richtlinie angewendet. Es gibt kein Konzept für eine Verbindung (oder einen Stream). Das Fehlen von Verbindungen hat mehrere wichtige Konsequenzen:
  • , , , ( Calico conntrack, ).
  • untracked workload Kubernetes (pod’), pod’.
  • NAT ( ​​ NAT conntrack).
  • « » untracked- . , , untracked- ( ).
  • Nicht verfolgte Richtlinien werden ganz am Anfang der Paketverarbeitungspipeline angewendet. Dies ist beim Erstellen von Calico-Richtlinien sehr wichtig. Sie können eine Richtlinie für einen Pod mit der Reihenfolge: 1 und eine nicht verfolgte Richtlinie mit der Reihenfolge: 1000 haben. Es wird nichts ausmachen. Die nicht verfolgte Richtlinie wird vor der Richtlinie für den Pod angewendet. Nicht verfolgte Richtlinien respektieren die Ausführungsreihenfolge nur untereinander.

Da eines der Ziele der doNotTrack-Richtlinie darin besteht, die Richtlinie in einem sehr frühen Stadium der Linux-Paketverarbeitungspipeline durchzusetzen, muss Calico bei Verwendung von doNotTrack die Option applyOnForward angeben. Beachten Sie unter Bezugnahme auf das Paketverarbeitungsdiagramm, dass die Richtlinie für nicht verfolgte (5) vor Routingentscheidungen angewendet wird. Der Datenverkehr kann an den Host-Prozess geleitet oder an einen Pod oder einen anderen Knoten umgeleitet werden.

Zusammenfassung


Wir haben uns die verschiedenen Richtlinienoptionen (Host-Endpunkt, ApplyOnForward, preDNAT und Untracked) in Calico und deren Anwendung auf die Paketverarbeitung angesehen. Das Verständnis der Essenz ihrer Arbeit hilft bei der Entwicklung effektiver und sicherer Richtlinien. Mit Calico können Sie die globale Netzwerkrichtlinie verwenden, die für das Label (eine Gruppe von Knoten und Pods) gilt, und Richtlinien mit verschiedenen Parametern anwenden. Auf diese Weise können Sicherheits- und Netzwerkdesignspezialisten „alles“ (Endpunkttypen) sofort mit derselben Richtliniensprache wie Calico-Richtlinien schützen.


Danksagung: Ich möchte Sean Crampton und Alex Pollitt für ihre Bewertung und für wertvolle Informationen danken .

More articles:


All Articles