Die virtuelle Netzwerkschicht auf der GDC-Appliance (Google Distributed Cloud) mit Air Gap regelt die Konnektivität, Firewalls, Service Discovery, das Load-Balancing und die Observability zwischen virtuellen Maschinen und Pods, die in einer GDC-Organisation ausgeführt werden.
GDC-Netzwerkmodell
GDC besteht aus einer Mandantenebene: Projekte.
Projektvernetzung
Sie stellen alle virtuellen Maschinen (VMs) und containerisierten Arbeitslasten in einem Projekt bereit. Projekte bilden eine Grenze für die Netzwerksegmentierung innerhalb der Organisation.
Arbeitslasten innerhalb eines Projekts können direkt miteinander kommunizieren. Die Standardnetzwerkrichtlinie verhindert jedoch die Kommunikation zwischen Arbeitslasten in verschiedenen Projekten. Wenn die Netzwerkrichtlinie des Projekts dies zulässt, können Workloads in der Organisation sich auf der L3-Netzwerkschicht über ihre jeweiligen IP-Adressen erreichen. Sie müssen Eingangs- und Ausgangs-Einschränkungen für die Organisation für jede Arbeitslast, die eingehenden oder ausgehenden Traffic erfordert, explizit aktivieren.
Load-Balancer konfigurieren
Load-Balancer verteilen den Traffic auf die Backend-Arbeitslasten Ihrer Anwendung und sorgen so für Stabilität und Verfügbarkeit. Externe und interne Load-Balancer für Pod- und VM-Arbeitslasten erstellen GDC bietet drei Methoden zum Konfigurieren von Load-Balancern. Weitere Informationen finden Sie unter Load Balancer verwalten.
Einschränkungen für eingehenden Traffic
Der Mechanismus, mit dem Arbeitslasten außerhalb der Organisation verfügbar gemacht werden, hängt davon ab, ob die Arbeitslast auf VMs oder Containern basiert.
Sie machen VM-basierte Arbeitslasten außerhalb der Organisation über die Funktion für den externen VM-Zugriff verfügbar. Sie aktivieren diese Funktion für jede VM. Jede VM erhält eine eigene IP-Adresse aus dem externen Bereich der Organisation.
Andererseits machen Sie containerisierte Arbeitslasten außerhalb der Organisation mithilfe der Funktion für externe Load-Balancer verfügbar. Sie können einen externen Load-Balancer erstellen. GDC weist ihm dann eine externe IP-Adresse zu. Der Traffic kann dann über eine Reihe von Backend-Pod-Arbeitslasten verteilt werden.
Einschränkungen für ausgehenden Traffic
Sie müssen ausgehenden Traffic für jedes Projekt und jede Arbeitslast explizit aktivieren, damit die Kommunikation außerhalb der Organisation möglich ist. Wenn ausgehender Traffic aktiviert ist, wird die IP-Adresse von Arbeitslasten in eine externe IP-Adresse übersetzt, wenn eine Verbindung außerhalb der Organisation hergestellt wird. Dazu wird die Netzwerkadressübersetzung (Network Address Translation, NAT) verwendet. Weitere Informationen zum Zulassen von ausgehendem Traffic finden Sie unter Ausgehenden Traffic einer Organisation verwalten.
Modell zur Durchsetzung von Netzwerkrichtlinien
Die Sicherheitslage für Arbeitslasten in einer Organisation ist die Kombination aus Standard- und benutzererstellten Projektnetzwerkrichtlinien.
Die Richtliniendurchsetzung basiert auf Layer 3- und Layer 4-Traffic-Flows. Ein Flow beschreibt eine 5-Tupel-Verbindung so:
- Quell-IP-Adresse
- IP-Adresse des Ziels
- Quellport
- Zielport
- Protokoll, z. B.
TCPoderUDP
Netzwerkrichtlinien erzwingen ausgehenden Traffic auf dem Knoten, auf dem die Quellarbeitslast gehostet wird, und eingehenden Traffic, wenn der Traffic auf dem Knoten ankommt, auf dem die Zielarbeitslast gehostet wird. Damit eine Verbindung hergestellt werden kann, muss die Richtlinie daher die Quelle für das Ziel verlassen und am Ziel von der Quelle aus eintreffen.
Antwort-Traffic, z. B. das SYN-ACK-Segment (Synchronize-Acknowledge), das auf ein SYN-Segment antwortet, unterliegt nicht der Durchsetzung. Antworttraffic ist daher immer zulässig, wenn der initiierende Traffic zulässig ist. Aus diesem Grund treten Zeitüberschreitungen bei der Verbindung aufgrund der Richtliniendurchsetzung nur beim Client auf, der die Verbindung initiiert. Abgelehnter Traffic wird entweder während der ausgehenden Datenübertragung vom Quellknoten oder während der eingehenden Datenübertragung am Zielknoten verworfen. Die empfangende Arbeitslast beobachtet die Verbindung nie.
Die Durchsetzung basiert auf zulassungsbasierten Richtlinienregeln, die additiv sind. Die resultierende Erzwingung für eine Arbeitslast ist ein „Beliebiger Abgleich“ für den Traffic-Flow in Bezug auf die Vereinigung aller auf diese Arbeitslast angewendeten Richtlinien. Wenn mehrere Richtlinien vorhanden sind, werden die auf jede Arbeitslast angewendeten Regeln additiv kombiniert. Traffic ist zulässig, wenn er mindestens einer der Regeln entspricht. Sie haben keine „deny“-Regeln, sondern nur „allow“-Regeln.
Wenn ein Flow durch eine Netzwerkrichtlinie abgelehnt wird, erhalten Sie kein Antwortpaket und es kommt zu einem Verbindungs-Timeout. Aus diesem Grund sind abgelehnte oder zurückgesetzte Verbindungen auf Protokollebene oder HTTP-Fehler keine direkte Folge der Netzwerkerzwingung.
Weitere Informationen zu Kubernetes-Netzwerkrichtlinien finden Sie unter https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation.