Best Practices für die Verwendung von Cloud Service Mesh-Ausgangsgateways für GKE-Cluster

In diesem Dokument wird die Verwendung des Cloud Service Mesh beschrieben Ausgangsgateways und andere Google Cloud-Steuerelemente zur Sicherung des ausgehenden Traffics (ausgehender Traffic) von Arbeitslasten, die in einem GKE-Cluster (Google Kubernetes Engine) bereitgestellt sind. Mit diesen Kontrollen lassen sich Verbindungen zu externen Diensten anhand der Identität der Quellanwendung, des Namespace eines Teams, der Zieldomain und anderer Attribute der ausgehenden Anfragen beschränken.

Das Dokument ist für Entwickler von Netzwerk-, Plattform- und Sicherheitsfunktionen gedacht, die GKE-Cluster verwalten, die von einem oder mehreren Teams für das Software-Deployment genutzt werden. Die hier beschriebenen Steuerelemente können besonders nützlich für Unternehmen, die die Compliance mit Bestimmungen (z. B. DSGVO) und PCI).

Einleitung

Der traditionelle Ansatz zur Netzwerksicherheit besteht darin, Sicherheitsperimeter für eine Gruppe von Anwendungen zu definieren. Für diese Perimeter werden Firewalls verwendet, um Traffic anhand der Quell- und Ziel-IP-Adresse zuzulassen oder abzulehnen, wobei im Perimeter vertrauenswürdige Anwendungen und vertrauenswürdiger Traffic festgelegt sind. Diese Festlegung als vertrauenswürdig birgt jedoch Risiken. Ein böswilliger Insider oder eine Person, die den Perimeter manipuliert, kann sich innerhalb des Netzwerks frei bewegen, auf Daten zugreifen und diese entwenden, Systeme von Drittanbietern angreifen und Verwaltungssysteme beeinträchtigen.

Wenn Arbeitslasten, die auf einem Kubernetes-Cluster ausgeführt werden, ausgehende Verbindungen zu Hosts im Internet herstellen, kann die Anwendung traditioneller IP-basierter Sicherheitskontrollen aus folgenden Gründen schwierig sein:

  • Pod-IP-Adressen geben nicht ausreichend die Identität der Arbeitslast wieder, die die Verbindung herstellt. In einer Kubernetes-Umgebung werden Pod-IP-Adressen sitzungsspezifisch zugewiesen und häufig wiederverwendet, wenn sich Pods ändern.

  • Es ist oft nicht möglich, einen überschaubaren festen Satz von IP-Adressen für bestimmte Zielhosts zu ermitteln. IP-Adressen ändern sich häufig, variieren je nach Region und können aus großen Bereichen stammen oder Caches, Proxys bzw. CDNs darstellen.

  • Wenn mehrere Teams einen mehrmandantenfähigen Cluster mit einem gemeinsamen Bereich von Quell-IP-Adressen teilen, können die Anforderungen für externe Verbindungen abweichen.

Cloud Service Mesh ist ein vollständig verwaltetes Service Mesh in Google Cloud. basierend auf dem Open-Source-Dienst Istio Mesh-Netzwerk. Ein Service Mesh bietet eine einheitliche Möglichkeit für das Herstellen einer Verbindung, die Verwaltung und den Schutz der Anwendungskommunikation. Service Meshes verfolgen einen anwendungsorientierten Ansatz und nutzen vertrauenswürdige Anwendungsidentitäten anstelle von netzwerkbezogenen IP-Adressen.

Sie können ein Service Mesh transparent bereitstellen, ohne vorhandenen Anwendungscode ändern zu müssen. Mit einem Service Mesh können Sie die Arbeit von Entwicklungsteams, die für das Deployment und Freigabe von Anwendungs-Features zuständig sind, von den Aufgaben der Netzwerkadministratoren durch eine deklarative Steuerung des Netzwerkverhaltens trennen.

Cloud Service Mesh bietet die Option zum Bereitstellen. eigenständige Forward-Proxys,sogenannte Ausgangs-Gateways, am Rand des Mesh-Netzwerks. In diesem Leitfaden wird erläutert, wie die Features des Egress-Gateway-Proxys mit Google Cloud-Features kombiniert werden können, um ausgehenden Traffic von Arbeitslasten, die in einem GKE-Cluster bereitgestellt werden, zu steuern, zu autorisieren und zu beobachten.

Konzeptionelle Komponenten

Gestaffelte Sicherheitsarchitektur

Das folgende Diagramm zeigt eine Architektur, die einen gestaffelten Sicherheitsansatz für eine detailgenaue Steuerung des ausgehenden Traffics eines Clusters verfolgt, der von mehreren Teams genutzt wird. Die Kontrollen basieren auf den Netzwerkkontrollebenen Layer 4 (Transport) und Layer 7 (Anwendung).

Gesamtarchitektur

Die Architektur verwendet die folgenden Ressourcen und Kontrollen:

  • Ein privater GKE-Cluster: Knoten in einem privaten GKE-Cluster haben nur interne IP-Adressen und sind standardmäßig nicht mit dem Internet verbunden.

  • Cloud NAT: Cloud NAT ermöglicht ausgehenden Internetzugriff vom privaten Cluster aus.

  • Firewallregeln für Virtual Private Cloud (VPC): Sie konfigurieren VPC-Firewallregeln, um die Kontrollen von Layer 4 (Transport) auf Verbindungen zu und von den Knoten im GKE-Cluster anzuwenden. Sie können VPC-Firewallregeln auf VMs anhand von Dienstkonten oder Netzwerk-Tags anwenden.

  • GKE-Knotenpools mit unterschiedlichen Dienstkonten: Damit können Sie verschiedene Firewallregeln konfigurieren, die je nach Knotenpool eines Knotens angewendet werden.

  • Kubernetes-Namespaces: Sie erstellen Namespaces für jedes Team, um diese zu isolieren und eine delegierte administrative Kontrolle zu ermöglichen. Netzwerkadministratoren verwenden einen dedizierten Namespace, um das Ausgangsgateway bereitzustellen und das Routing zu externen Hosts zu konfigurieren.

  • Kubernetes-Netzwerkrichtlinien: Mithilfe von Netzwerkrichtlinien können Sie Layer-4-Kontrollen auf Pods anwenden. Jede Netzwerkrichtlinie ist auf einen Namespace beschränkt und kann zusätzlich noch detaillierter auf einzelne Pods in einem Namespace angewendet werden.

  • Ausgangsgateway: Der Traffic, der von Pods innerhalb des Mesh-Netzwerks ausgeht, wird über dedizierte Ausgangsgateway-Proxys geleitet, die auf dedizierten Knoten ausgeführt werden. Sie stellen Ausgangsgateways mit einem horizontalen Pod-Autoscaling bereit, sodass die Anzahl der Replikate je nach Traffic hoch- und herunterskaliert werden kann.

  • Autorisierungsrichtlinien: Mithilfe von Mesh-Autorisierungsrichtlinien können Sie die Kontrollen von Layer 7 (Anwendung) auf Traffic zwischen Pods im Mesh-Netzwerk sowie auf Traffic anwenden, der vom Mesh-Netzwerk ausgeht.

  • Sidecar-Ressourcen: Mit Sidecar-Ressourcen steuern Sie den Konfigurationsbereich der Sidecar-Proxys, die in den einzelnen Arbeitslast-Pods ausgeführt werden. Sie können mithilfe der Sidecar-Ressource die Namespaces, Pods und externen Dienste konfigurieren, die für eine Arbeitslast sichtbar sind.

  • Privater Google-Zugriff: Mit dieser Option können Knoten und Pods im privaten Cluster auf Google APIs zugreifen und Docker-Images aus Container Registry abrufen.

  • GKE Workload Identity: Mit Workload Identity können Sie mithilfe der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) bestimmten Arbeitslasten API-Berechtigungen gewähren und dazu das Prinzip der geringsten Berechtigung anwenden, ohne Secrets nutzen zu müssen.

Kontrollen für ausgehenden Traffic konfigurieren

Wenn Sie mit dem Ausgangsgateway von Ihrem Mesh-Netzwerk ausgehenden Traffic schützen möchten, empfehlen wir, die in diesem Abschnitt beschriebenen Kontrollen für gestaffelte Sicherheitsebenen zu konfigurieren.

Private GKE mit Cloud NAT verwenden

Wenn die Sicherheit eine wichtige Rolle spielt, möchten viele Unternehmen vor allem ihren Arbeitslasten keine öffentlichen IP-Adressen zuweisen. Mit einem privaten GKE-Cluster wird diese Anforderung erfüllt. Sie können den VPC-nativen Modus in Ihrem privaten Cluster so konfigurieren, dass Pods und Diensten IP-Adressen aus sekundären Bereichen der VPC zugewiesen werden. IP-Adressen von nativen VPC-Pods sind im VPC-Netzwerk nativ routingfähig.

Einige Arbeitslasten benötigen möglicherweise Zugriff auf Dienste außerhalb des VPC-Netzwerks und im Internet. Damit Arbeitslasten eine Verbindung zu externen Hosts herstellen können, ohne öffentliche IP-Adressen einrichten, konfigurieren Cloud NAT um Network Address Translation (NAT) bereitzustellen.

Achten Sie darauf, dass Cloud NAT so konfiguriert ist, dass das Ausgangsgateway eine ausreichende Anzahl gleichzeitiger Verbindungen zu externen Zielen herstellen kann. Sie können eine Port-Erschöpfung und Probleme durch Verzögerungen bei der Wiederverwendung von Verbindungen vermeiden, wenn Sie eine erforderliche Mindestanzahl an Ports pro VM entsprechend festlegen. Ausführliche Informationen dazu finden Sie unter Cloud NAT-Adresse und Portübersicht. Durch Erhöhung der Anzahl an Ausgangsgateway-Replikaten können Sie der Gefahr von endpunktunabhängigen Zuordnungskonflikten vorbeugen.

Privaten Google-Zugriff für Google APIs und Dienste konfigurieren

Es ist davon auszugehen, dass Ihre Arbeitslasten Zugriff auf Google APIs und Google-Dienste benötigen. Verwenden Sie den privaten Google-Zugriff mit benutzerdefinierten DNS-Zonen, um Verbindungen von privaten VPC-Subnetzen zu Google APIs mit einem Satz von vier IP-Adressen zu ermöglichen. Durch Nutzung dieser IP-Adressen benötigen die Pods keine externen IP-Adressen. Der Traffic verlässt dann nie das Google-Netzwerk. Sie können private.googleapis.com (199.36.153.8/30 ) oder restricted.googleapis.com (199.36.153.4/30) verwenden, je nachdem, ob Sie VPC Service Controls nutzen.

Google APIs und Dienste mithilfe von Workload Identity und IAM noch besser schützen

Die Verwendung von Workload Identity wird empfohlen, um GKE-Arbeitslasten die Authentifizierung bei Google APIs zu ermöglichen. Außerdem können Administratoren damit eine Autorisierung mit der geringsten Berechtigung mithilfe von IAM festlegen.

Wenn Sie den privaten Google-Zugriff, Workload Identity und IAM verwenden, können Sie risikolos Arbeitslast-Pods erlauben, das Ausgangsgateway zu umgehen und direkt eine Verbindung zu Google APIs und Diensten herzustellen.

Kubernetes-Namespaces für administrative Kontrolle verwenden

Namespaces sind eine Organisationsressource, die in Umgebungen mit vielen Nutzern, Teams oder Mandanten hilfreich ist. Sie können wie ein virtueller Cluster betrachtet werden und bieten die Möglichkeit, die administrative Verantwortung für Gruppen von Kubernetes-Ressourcen an unterschiedliche Administratoren zu delegieren.

Namespaces sind ein wichtiges Feature zur Isolation der administrativen Kontrolle. Damit werden aber standardmäßig keine Knotenisolation, keine Isolation von Datenebenen und keine Netzwerkisolation bereitgestellt.

Cloud Service Mesh basiert auf Kubernetes-Namespaces, die als Mandanteneinheit in einem Service Mesh verwendet werden. Mesh-Autorisierungsrichtlinien und Sidecar-Ressourcen können die Transparenz und den Zugriff anhand von Namespace, Identität und Layer 7-Attributen (Anwendung) des Netzwerktraffics einschränken.

Ebenso bieten Kubernetes-Netzwerkrichtlinien die Möglichkeit, Netzwerkverbindungen auf Layer 4 (Transport) zuzulassen oder abzulehnen.

Ausgangsgateways auf dedizierten Gatewayknoten ausführen

Das Ausführen von Ausgangsgateways auf Knoten in einem dedizierten Gatewayknotenpool bietet verschiedene Vorteile. Die extern erreichbaren Knoten können eine gehärtete Konfiguration verwenden. Außerdem haben Sie die Möglichkeit, VPC-Firewallregeln so zu konfigurieren, dass Arbeitslasten keine externen Hosts erreichen können. Die Knotenpools lassen sich gesondert mithilfe des Cluster-Autoscalings automatisch skalieren.

Für eine separate administrative Kontrolle des Ausgangsgateways stellen Sie es in einem dedizierten istio-egress-Namespace bereit. Namespaces sind dagegen eine projektübergreifende Ressource. Damit kann nicht festgelegt werden, auf welchen Knoten das Deployment ausgeführt wird. Um das Deployment zu steuern, verwenden Sie eine Knotenauswahl für das Deployment des Ausgangsgateways, damit es auf Knoten ausgeführt wird, die als Mitglieder des Gatewayknotenpools gekennzeichnet sind.

Auf Gatewayknoten sollen nur Gateway-Pods ausgeführt werden können. Andere Pods sollten für Gatewayknoten nicht zulässig sein, da sonst die Kontrollen für ausgehenden Traffic umgangen werden können. Die Ausführung von Arbeitslasten auf bestimmten Knoten lässt sich mithilfe von Markierungen und Toleranzen verhindern. Sie müssen dazu die entsprechenden Knoten im Gatewayknotenpool markieren und eine entsprechende Toleranz dem Deployment des Ausgangsgateways hinzufügen.

VPC-Firewallregeln auf bestimmte Knoten anwenden

Sie konfigurieren das Service Mesh-Routing so, dass ausgehender Traffic von den Arbeitslasten, die im Standardknotenpool ausgeführt werden, über die im Gatewayknotenpool ausgeführten Ausgangsgateways geleitet wird. Die Routingkonfiguration des Mesh-Netzwerks sollte jedoch nicht als Sicherheitsgrenze angesehen werden, da die Mesh-Proxys auf verschiedene Arten von der Arbeitslast umgangen werden können.

Um zu verhindern, dass Anwendungsarbeitslasten direkt mit externen Hosts verbunden werden, wenden Sie einschränkende Firewallregeln für ausgehenden Traffic auf die Knoten im Standardknotenpool an. Wenden Sie separate Firewallregeln auf die Gatewayknoten an, damit die auf ihnen ausgeführten Pods für das Ausgangsgateway mit externen Hosts verbunden werden können.

Beim Erstellen einer VPC-Firewallregel geben Sie die Ports und Protokolle an, die von der Firewallregel zugelassen oder abgelehnt werden sollen, sowie die Richtung des jeweiligen Traffics. Ausgangsregeln gelten für ausgehenden Traffic und Eingangsregeln für eingehenden Traffic. Der Standardwert für ausgehenden Traffic ist allow, der Standardwert für eingehenden Traffic lautet deny.

Firewallregeln werden gemäß einer Prioritätsnummer angewendet, die Sie festlegen können. Firewallregeln sind zustandsorientiert. Wenn also ein bestimmter Traffic von einer VM zugelassen ist, kann über diese Verbindung auch Traffic zurückgeleitet werden kann.

Das folgende Diagramm zeigt, wie separate Firewallregeln auf zwei verschiedene Knotenpools anhand des Dienstkontos angewendet werden können, das einem Knoten zugewiesen ist. In diesem Fall wird durch eine Standard-deny all-Firewallregel der ausgehende Zugriff für die gesamte VPC verweigert. Damit die Standard-Firewallregeln, die für die Nutzung des Clusters erforderlich sind, nicht überschrieben werden, sollte die deny all-Regel eine niedrige Priorität wie z. B. „65535“ haben. Auf die Gatewayknoten wird eine zusätzliche Firewallregel für ausgehenden Traffic mit höherer Priorität angewendet, die eine direkte Verbindung zu externen Hosts an den Ports 80 und 443 erlaubt. Der Standardknotenpool hat keinen Zugriff auf externe Hosts.

Firewallknotenpool

Kubernetes-Netzwerkrichtlinien als Firewall für Pods und Namespaces verwenden

Mit Kubernetes-Netzwerkrichtlinien können Sie eine zusätzliche Sicherheitsebene im Rahmen einer gestaffelten Sicherheitsstrategie anwenden. Netzwerkrichtlinien beziehen sich auf Namespaces und Layer 4 (Transport). Mit Netzwerkrichtlinien können Sie folgenden eingehenden und ausgehenden Traffic einschränken:

  • Zwischen Namespaces
  • Zu Pods in einem Namespace
  • Zu bestimmten Ports und IP-Blöcken

Wenn eine Netzwerkrichtlinie Pods in einem Namespace auswählt, werden alle nicht explizit zugelassenen Verbindungen abgelehnt. Wenn mehrere Netzwerkrichtlinien vorhanden sind, werden diese additiv angewendet, d. h. es gelten immer alle Richtlinien. Die Reihenfolge, in der die Richtlinien angewendet werden, spielt dabei keine Rolle.

Hier einige Beispiele für Netzwerkrichtlinien:

  • Es werden ausgehende Verbindungen von den Arbeitslast-Namespaces zu den Namespaces istio-system und istio-egress zugelassen. Pods müssen eine Verbindung herstellen können die Steuerungsebene und das Ausgangsgateway.
  • Es wird zugelassen, dass Arbeitslasten DNS-Abfragen von den Arbeitslast-Namespaces an Port 53 im Namespace kube-system ausführen.
  • Optional: Es wird zugelassen, dass Arbeitslasten in einem Namespace eine Verbindung zueinander herstellen.
  • Optional: Es werden ausgehende Verbindungen zwischen den Namespaces zugelassen, die von unterschiedlichen Anwendungsteams verwendet werden.
  • Es werden ausgehende Verbindungen von Arbeitslast-Namespaces zu den VIPs für die Google APIs, die über den privaten Google-Zugriff bereitgestellt werden, zugelassen. Cloud Service Mesh bietet eine verwaltete Zertifizierungsstelle und stellt sie als API bereit, sodass die Sidecar-Proxys in der Lage sein müssen, eine Verbindung zu ihr herzustellen. Einige Arbeitslasten benötigen außerdem vermutlich Zugriff auf Google APIs.
  • Es werden ausgehende Verbindungen von Arbeitslast-Namespaces zum GKE-Metadatenserver zugelassen, sodass die Sidecar-Proxys und die Arbeitslasten Metadatenabfragen ausführen und sich bei Google APIs authentifizieren können.

Wenn ein Sidecar-Proxy in einen Arbeitslast-Pod eingefügt wird, werden standardmäßig iptables-Regeln programmiert, sodass der Proxy den gesamten eingehenden und ausgehenden TCP-Traffic erfasst. Wie bereits erwähnt, gibt es aber Möglichkeiten für Arbeitslasten, den Proxy zu umgehen. VPC-Firewallregeln verhindern einen direkten ausgehenden Zugriff von den Standardknoten, auf denen die Arbeitslasten ausgeführt werden. Mit Kubernetes-Netzwerkrichtlinien können Sie dafür sorgen, dass kein direkter externer ausgehender Traffic aus Arbeitslast-Namespaces und ausgehender Traffic zum Namespace istio-egress möglich ist.

Wenn Sie auch eingehenden Traffic mit Netzwerkrichtlinien steuern, müssen Sie dafür Richtlinien erstellen, die Ihren Richtlinien für ausgehenden Traffic entsprechen.

Service-Mesh-Konfiguration und -Sicherheit

Arbeitslasten, die in einem Service Mesh ausgeführt werden, werden nicht anhand ihrer IP-Adressen identifiziert. Cloud Service Mesh weist eine starke und überprüfbare Identität im X.509-Zertifikat und Schlüssel für jede Arbeitslast. Die vertrauenswürdige Kommunikation zwischen Arbeitslasten wird mithilfe von authentifizierten und verschlüsselten mTLS-Verbindungen (gegenseitiges TLS) hergestellt.

Durch Verwendung der mTLS-Authentifizierung mit einer eindeutig definierten Identität für jede Anwendung können Sie Mesh-Autorisierungsrichtlinien für eine detaillierte Steuerung der Kommunikation von Arbeitslasten mit externen Diensten nutzen.

Obwohl Traffic das Mesh-Netzwerk direkt von den Sidecar-Proxys verlassen kann, empfehlen wir zur besseren Kontrolle die Weiterleitung des Traffics über Ausgangsgateways, wie in diesem Leitfaden beschrieben.

Konfiguration der Kontrollen für ausgehenden Traffic in einem dedizierten Namespace verwalten

Ermöglichen Sie Netzwerkadministratoren die zentrale Verwaltung von Kontrollen durch Verwendung eines dedizierten istio-egress-Namespace für die Mesh-Konfiguration von ausgehendem Traffic. Wie zuvor empfohlen, stellen Sie das Ausgangsgateway für den Namespace istio-egress bereit. Sie können in diesem Namespace Diensteinträge, Gateways und Autorisierungsrichtlinien erstellen und verwalten.

Explizite Konfiguration externer Ziele erforderlich machen

Achten Sie darauf, dass Mesh-Proxys nur mit Routen zu externen Hosts programmiert werden, die explizit in der Service Mesh-Registry definiert sind. Legen Sie für den Modus der Richtlinie für ausgehenden Traffic den Wert REGISTRY_ONLY in einer standardmäßigen Sidecar-Ressource für jeden Namespace fest. Das Festlegen der Richtlinie für ausgehenden Traffic für das Mesh allein sorgt noch nicht für eine sichere Perimeterkontrolle.

Externe Ziele mit Diensteinträgen definieren

Konfigurieren Diensteinträge um externe Hosts explizit in der Dienstregistrierung des Mesh-Netzwerks zu registrieren. Standardmäßig sind Diensteinträge für alle Namespaces sichtbar. Mit dem Attribut exportTo können Sie festlegen, für welche Namespaces ein Diensteintrag sichtbar ist. Diensteinträge legen die ausgehenden Routen, die in Mesh-Proxys konfiguriert sind, fest, sind aber allein noch keine sichere Kontrolle, um zu bestimmen, zu welchen externen Hosts Arbeitslasten eine Verbindung herstellen können.

Verhalten des Ausgangsgateways mit der Gatewayressource konfigurieren

Konfigurieren Sie das Load Balancing-Verhalten von Ausgangsgateways mithilfe der Ressource Gateway. Der Load-Balancer kann für eine bestimmte Gruppe von Hosts, Protokollen und Ports konfiguriert und mit dem Deployment eines Ausgangsgateways verknüpft werden. Beispielsweise besteht die Möglichkeit, ein Gateway für ausgehenden Traffic zu den Ports 80 und 443 für jeden externen Host zu konfigurieren.

In Cloud Service Mesh ist automatisches mTLS standardmäßig aktiviert. Bei automatischem mTLS erkennt ein Client-Sidecar-Proxy automatisch, ob der Server einen Sidecar hat. Der Client-Sidecar-Proxy sendet an Arbeitslasten mit Sidecars mTLS und an Arbeitslasten ohne Sidecars Nur-Text-Traffic. Auch bei automatischem mTLS wird für Traffic, der von Sidecar-Proxys an das Ausgangsgateway gesendet wird, nicht automatisch mTLS verwendet. Um anzugeben, wie Verbindungen zum Ausgangsgateway geschützt werden sollen, müssen Sie für die Gatewayressource den TLS-Modus festlegen. Verwenden Sie nach Möglichkeit für Verbindungen von Sidecar-Proxys zum Ausgangsgateway mTLS.

Es kann festgelegt werden, dass Arbeitslasten TLS-Verbindungen (HTTPS) selbst initiieren. Wenn Arbeitslasten TLS-Verbindungen herstellen – in der Regel an Port 443 –, müssen Sie das Gateway für die Verwendung des passthrough-Modus für Verbindungen zu diesem Port konfigurieren. Bei Verwendung des passthrough-Modus kann das Gateway aber keine Autorisierungsrichtlinien anhand der Identität der Arbeitslast oder der Attribute der verschlüsselten Anfrage anwenden. Darüber hinaus ist es aktuell nicht möglich, mTLS und passthrough gemeinsam zu verwenden.

TLS-Weiterleitung

Virtuelle Dienste und Zielregeln für das Weiterleiten von Traffic über das Gateway konfigurieren

Verwenden Sie Virtuelle Dienste und Zielregeln um das Routing des Traffics von Sidecar-Proxys durch den ausgehenden Traffic zu konfigurieren Gateway zu externen Zielen. Virtuelle Dienste definieren Regeln für den Abgleich eines bestimmten Traffics. Übereinstimmender Traffic wird dann an ein Ziel gesendet. Mit Zielregeln können Sie Teilelemente (z. B. das Ausgangsgateway oder einen externen Host) definieren und festlegen, wie der Traffic verarbeitet werden soll, wenn er an das Ziel weitergeleitet wird.

Verwenden Sie eine einzelne Zielregel für mehrere Zielhosts, um explizit anzugeben, wie der Traffic von Sidecar-Proxys zum Gateway geschützt werden soll. Wie bereits erläutert, wird empfohlen, dass Arbeitslasten Nur-Text-Anfragen senden und der Sidecar-Proxy eine mTLS-Verbindung zum Gateway herstellt.

Verwenden Sie eine Zielregel für jeden externen Host, um das Ausgangsgateway für das „Ändern“ von einfachen HTTP-Anfragen zur Verwendung einer TLS-Verbindung (HTTPS) zu konfigurieren, wenn an das Ziel weitergeleitet wird. Das Umstellen einer Nur-Text-Verbindung auf TLS wird häufig als Herstellen eines TLS-Ursprungs bezeichnet.

Geltungsbereich der Proxykonfiguration mit der Sidecar-Ressource festlegen

Standardeinstellung konfigurieren Sidecar-Ressource für jeden Namespace, um das Verhalten der Sidecar-Proxys zu steuern. Verwenden Sie die Methode egress-Property der Sidecar-Ressource, um die konfigurierten Zielhosts zu steuern und zu minimieren in den ausgehenden Listenern der Proxys. Eine typische Mindestkonfiguration kann die folgenden Ziele für jeden Namespace enthalten:

  • Pods im selben Namespace
  • Google APIs und Google-Dienste
  • GKE-Metadatenserver
  • Bestimmte externe Hosts, die mithilfe von Diensteinträgen konfiguriert wurden

Die Konfiguration der ausgehenden Listener in Sidecar-Proxys sollte nicht die einzige Sicherheitseinstellung sein.

Es wird empfohlen, mithilfe von Sidecar-Ressourcen die Größe der Proxykonfiguration zu begrenzen. Standardmäßig ist jeder Sidecar-Proxy in einem Mesh-Netzwerk so konfiguriert, dass er Traffic an jeden anderen Proxy senden kann. Der Arbeitsspeicherverbrauch von Sidecar-Proxys und der Steuerungsebene kann erheblich reduziert werden, wenn die Konfiguration von Proxys auf diejenigen Hosts beschränkt wird, mit denen sie kommunizieren müssen.

Autorisierungsrichtlinie zum Zulassen oder Ablehnen von Traffic am Ausgangsgateway verwenden

AuthorizationPolicy ist eine Ressource, mit der Sie eine detaillierte Zugriffssteuerungsrichtlinie für Mesh-Traffic konfigurieren können. Sie haben die Möglichkeit, Richtlinien zu erstellen, um Traffic anhand der Attribute der Quelle, des Ziels oder des Traffics selbst (z. B. der Host oder die Header einer HTTP-Anfrage) zuzulassen oder abzulehnen.

Um Verbindungen auf Grundlage der Identität oder des Namespaces der Quellarbeitslast zuzulassen oder abzulehnen, muss die Verbindung zum Ausgangsgateway mit mTLS authentifiziert werden. Für Verbindungen von Sidecars zum Ausgangsgateway wird nicht automatisch mTLS verwendet. Daher muss in der Zielregel für Verbindungen zum Gateway der TLS-Modus ISTIO_MUTUAL explizit angegeben werden.

Damit Anfragen an das Gateway mithilfe von Autorisierungsrichtlinien zugelassen oder abgelehnt werden, müssen Arbeitslasten einfache HTTP-Anfragen an Ziele außerhalb des Mesh-Netzwerks senden. Die Sidecar-Proxys können die Anfrage dann mit mTLS an das Gateway weiterleiten. Das Gateway hat schließlich die Möglichkeit, eine sichere TLS-Verbindung zum externen Host herzustellen.

Um die Anforderungen für ausgehenden Traffic von verschiedenen Teams und Anwendungen zu unterstützen, müssen Sie separate Autorisierungsrichtlinien mit den geringsten Berechtigungen pro Namespace oder Arbeitslast konfigurieren. Zum Beispiel können Sie auf den Ausgangsgateway unterschiedliche Richtlinien anwenden und dafür Regeln anhand des Namespace der Quellarbeitslast und der Attribute der Anfrage so festlegen:

  • Wenn der Quell-Namespace team-x UND der Zielhost example.com lautet, ist Traffic zugelassen.

    Beispiel für Autorisierungsrichtlinien

  • Wenn der Quell-Namespace team-y UND der Zielhost httpbin.org UND der Pfad /status/418 lautet, ist Traffic zugelassen.

    Autorisierungsrichtlinien mit httpbin

Alle anderen Anfragen werden abgelehnt.

Ausgangsgateway zum Herstellen von TLS-Verbindungen (HTTPS) zum Ziel konfigurieren

Konfigurieren Sie Zielregeln so, dass das Ausgangsgateway TLS-Verbindungen (HTTPS) zu externen Zielen herstellt.

Damit der TLS-Ursprung für das Ausgangsgateway funktioniert, müssen Arbeitslasten einfache HTTP-Anfragen senden. Wenn die Arbeitslast TLS initiiert, kapselt das Ausgangsgateway TLS zusätzlich zum ursprünglichen TLS und Anfragen an den externen Dienst schlagen fehl.

Da Arbeitslasten einfache HTTP-Anfragen senden, konfigurieren Sie den Sidecar-Proxy der Arbeitslast, um eine mTLS-Verbindung für das Senden an das Gateway einzurichten. Das Ausgangsgateway beendet dann die mTLS-Verbindung und stellt eine reguläre TLS-Verbindung (HTTPS) zum Zielhost her.

TLS-Ursprung am Ausgangsgateway

Dieser Ansatz bietet verschiedene Vorteile:

  • Mit einer Autorisierungsrichtlinie können Sie Traffic anhand von Attributen der Quellarbeitslast und der Anfragen zulassen oder ablehnen.

  • Traffic zwischen Arbeitslast-Pods und dem Ausgangsgateway wird verschlüsselt und authentifiziert (mTLS); Traffic zwischen dem Ausgangsgateway und dem Ziel (TLS/HTTPS) wird verschlüsselt.

  • In einem Mesh-Netzwerk können Sidecar-Proxys die Attribute von HTTP-Anfragen (z. B. Header) beobachten und darauf reagieren. Dies bietet zusätzliche Optionen für Beobachtbarkeit und Kontrolle.

  • Anwendungscode kann vereinfacht werden. Entwickler müssen weder Zertifikate verarbeiten noch HTTPS-Clientbibliotheken nutzen. Das Service Mesh sorgt für eine sichere Kommunikation mit standardmäßigen und aktuellen Chiffren.

  • TLS-Verbindungen, die das Ausgangsgateway zu externen Diensten herstellt, können für Traffic von vielen Pods wiederverwendet werden. Die Wiederverwendung von Verbindungen ist effizienter und verringert das Risiko, dass das Verbindungslimit erreicht wird.

DNS, Hostnamen und Platzhalter

Beim Weiterleiten, Ablehnen oder Zulassen von Traffic anhand des Zielhosts muss die Integrität Ihrer DNS-Systeme gewährleistet sein, um DNS-Namen in die richtige IP-Adresse aufzulösen. In Kubernetes Engine-Clustern verarbeitet der Kubernetes-DNS-Dienst DNS-Abfragen und delegiert gleichzeitig externe Abfragen an den GKE-Metadatenserver und das interne DNS. Legen Sie für das Auflösungsattribut der Diensteinträge für das Weiterleiten zu externen Hosts den Wert „DNS“ fest, damit die Sidecar-Proxys für DNS-Abfragen verwendet werden können.

Cloud Service Mesh kann Traffic basierend auf Platzhalterhosts weiterleiten. Der einfachste Fall ist ein Platzhalter für Hosts mit einem gemeinsamen Namen, die auf einer gemeinsamen Gruppe von Servern gehostet werden. Wenn beispielsweise eine einzelne Gruppe von Servern die Domains bereitstellen kann, die mit *.example.com übereinstimmen, kann ein Platzhalterhost verwendet werden.

Ein standardmäßiges Ausgangsgateway kann aufgrund von bestimmten Einschränkungen des von Istio verwendeten Envoy-Proxys Traffic nicht auf Grundlage mehr allgemeiner und zufälliger Platzhalterhosts (z. B. *.com) weiterleiten. Envoy kann Traffic nur an vordefinierte Hosts, vordefinierte IP-Adressen oder an die ursprüngliche Ziel-IP-Adresse einer Anfrage weiterleiten. Bei Verwendung eines Ausgangsgateways geht die ursprüngliche Ziel-IP-Adresse der Anfrage verloren, da sie durch die IP-Adresse des Gateways ersetzt wird und die zufälligen Zielhosts nicht vorkonfiguriert werden können.

Richtlinien administrativ durchsetzen

Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Kubernetes verwenden

Die Konfiguration der Kontrollen für ausgehenden Traffic sollte nur für autorisierte Administratoren möglich sein. Konfigurieren Sie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes, um die unbefugte Umgehung von Kontrollen für ausgehenden Traffic zu verhindern. Wenden Sie RBAC-Rollen an, damit nur Netzwerkadministratoren die Namespaces istio-egress, istio-system, und kube-system sowie die folgenden Ressourcen verwalten können:

  • Sidecar
  • ServiceEntry
  • Gateway
  • AuthorizationPolicy
  • NetworkPolicy

Verwendung von Toleranzen beschränken

Wie weiter oben erläutert können Sie mit Markierungen und Toleranzen verhindern, dass Arbeitslast-Pods auf Gatewayknoten bereitgestellt werden. Standardmäßig lässt sich jedoch nicht verhindern, dass Arbeitslasten mit einer Toleranz für die Gatewayknoten bereitgestellt werden. Daher können Kontrollen für ausgehenden Traffic umgangen werden. Wenn es möglich ist, eine zentrale administrative Kontrolle von Deployment-Pipelines zu erzwingen, lassen sich damit bestimmte Einschränkungen für die Verwendung bestimmter Toleranzschlüssel verbindlich festlegen.

Ein weiterer Ansatz ist die Verwendung der Kubernetes-Zugriffskontrolle. Anthos enthält eine Komponente namens Policy Controller, die als Kubernetes-Zugriffskontrolle dient und validiert, ob Deployments die von Ihnen festgelegten Richtlinieneinschränkungen erfüllen.

Protokollierung des Traffics ermöglichen

Oft muss der gesamte Traffic protokolliert werden, der die Netzwerkperimeter durchläuft. Das Traffic-Logging ist z. B. erforderlich, wenn Sie die Einhaltung der gängigen Datenschutzvorschriften nachweisen müssen. Traffic-Logs werden direkt an Cloud Logging gesendet und es besteht die Möglichkeit, sie über die Cloud Service Mesh-Dashboards in der Google Cloud Console aufzurufen. Sie können Logs anhand verschiedener Attribute filtern, wie z. B. Quelle/Ziel, Identität, Namespace, Attribute des Traffics und Latenz.

Um eine einfache Fehlerbehebung mit kubectl zu ermöglichen, aktivieren Sie das Traffic-Logging für stdout, wenn Cloud Service Mesh mithilfe des Einstellung "accessLogFile".

Audit-Logs werden jedes Mal an Cloud Logging gesendet, wenn die Mesh-Zertifizierungsstelle ein Zertifikat für eine Arbeitslast erstellt.

Verwendung eines separaten Clusters für Ausgangsgateways in Multi-Cluster-Mesh-Netzwerken prüfen

Cloud Service Mesh kann die in mehr als einem GKE-Cluster bereitgestellt werden. Multi-Cluster-Mesh-Netzwerke bieten neue Möglichkeiten zur Steuerung des ausgehenden Traffics, führen aber auch zu gewissen Einschränkungen.

Anstatt das Ausgangsgateway in einem dedizierten Knotenpool bereitzustellen, können Sie das Gateway in einem separaten Cluster bereitstellen, in dem keine regulären Arbeitslasten ausgeführt werden. Die Verwendung eines separaten Clusters ermöglicht eine ähnliche Isolation von Arbeitslasten und Gateways, ohne dass Markierungen und Toleranzen genutzt werden müssen. Das Ausgangsgateway kann den separaten Cluster mit Eingangsgateways oder anderen zentrale Diensten teilen.

Sie können Kubernetes-Netzwerkrichtlinien in Multi-Cluster-Deployments verwenden. Da sie aber für Layer 4 (Transport) gelten, können clusterübergreifende Verbindungen nicht auf Grundlage des Ziel-Namespace oder -Pods eingeschränkt werden.

Nächste Schritte