Die virtuelle Netzwerkschicht in Google Distributed Cloud (GDC) Air-Gapped regelt die Konnektivität, Firewalls, Dienstermittlung, Lastenausgleich und Observability zwischen virtuellen Maschinen und Pods, die in einer GDC-Organisation ausgeführt werden.
GDC-Netzwerkmodell
GDC enthält zwei Ebenen von Multi-Tenancy-Konzepten: Organisationen und Projekte. Projekte sind in Organisationen vorhanden und Sie stellen alle virtualisierten und containerisierten Arbeitslasten in einem bestimmten Projekt innerhalb einer Organisation bereit.
Netzwerk der Organisation
Jede Organisation in GDC hat ihr eigenes isoliertes virtuelles Netzwerk. Das virtuelle Netzwerk innerhalb der Organisation ist ein flacher IP-Adressraum. Das bedeutet, dass alle Arbeitslasten in der Organisation eine direkte IP-Adressverbindung zueinander haben. Mit Projektnetzwerkrichtlinien können Sie den Zugriff zwischen Arbeitslasten in verschiedenen Projekten in der Organisation steuern.
GDC isoliert jede Organisation auf Netzwerkebene von allen anderen Organisationen. Arbeitslasten in einer Organisation haben keine direkte IP-Adressverbindung zu Arbeitslasten in einer anderen Organisation.
Eine Organisation hat zwei verschiedene IP-Bereiche: einen internen und einen externen. Der externe IP-Bereich ist von außerhalb der Organisation erreichbar und der interne IP-Bereich ist nur innerhalb der Organisation zugänglich. Arbeitslasten wird immer eine IP-Adresse aus dem internen Bereich der Organisation zugewiesen. Das bedeutet, dass sie standardmäßig nicht von außerhalb der Organisation aus zugänglich sind. Sie müssen eingehenden und ausgehenden Traffic für Arbeitslasten explizit aktivieren. Verwenden Sie dazu die im Abschnitt Projektnetzwerk beschriebenen Ingress- und Egress-Einschränkungen.
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. Mit Projektnetzwerkrichtlinien (ProjectNetworkPolicy) können Sie konfigurieren, welche Projekte in der Organisation miteinander kommunizieren dürfen. 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.