Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Ausgehenden Ambient-Traffic über Secure Web Proxy weiterleiten

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie das ausgehende Routing für Arbeitslasten, die im Ambient Networking von Google Kubernetes Engine (GKE) ausgeführt werden, zu einem Secure Web Proxy-Gateway (SWP) konfigurieren.

Wenn Sie ausgehenden Traffic über ein Secure Web Proxy-Gateway weiterleiten, können Sie zentrale Sicherheitsrichtlinien für ausgehenden Traffic erzwingen, z. B. URL-Filterung, Domain-Zulassungslisten und TLS-Prüfung, ohne Ihren Anwendungscode zu ändern. Der Layer-4-Knotenproxy fängt ausgehenden Traffic außerhalb des Anwendungs-Pods ab und bietet so eine Sicherheitsisolation außerhalb des Pods, selbst wenn ein Arbeitslastcontainer manipuliert wurde.

Architektur und Trafficfluss

Bei diesem Bereitstellungsmodell behalten Sie die Eigentümerschaft der Infrastruktur, einschließlich des GKE-Cluster, der Secure Web Proxy-Instanz und aller Private Service Connect-Endpunkte (PSC) für VPC-übergreifende Bereitstellungen.

Der ausgehende Traffic-Fluss funktioniert so:

Ein Arbeitslast-Pod initiiert ausgehenden Traffic an einen externen Endpunkt oder ein Internetziel.
Der lokale Layer-4-Ambient-Knotenproxy fängt die ausgehende Anfrage auf dem Knoten ab.
Der Knotenproxy stellt einen HTTP-CONNECT-Tunnel zum Gateway für ausgehenden Traffic her.
Wenn sich der Secure Web Proxy im selben VPC-Netzwerk befindet, wird der Traffic direkt mit dem Gateway verbunden. Wenn sich der Secure Web Proxy in einem anderen VPC-Netzwerk befindet, wird der Traffic über einen PSC-Dienstanhang geleitet.
Der Secure Web Proxy beendet den Tunnel, erzwingt konfigurierte Sicherheitsrichtlinien für ausgehenden Traffic und leitet autorisierte Anfragen an das Ziel weiter.

Beschränkungen

Bevor Sie das ausgehende Routing für Secure Web Proxy einrichten, sollten Sie sich die folgenden Einschränkungen in der Vorabversion ansehen:

Namespace-weite Richtlinien: Routingrichtlinien für ausgehenden Traffic gelten nur auf Namespace-Ebene. Eine detaillierte Pod-Auswahl mithilfe von Label-Selektoren wird nicht unterstützt.
Für die Hostnamenfilterung ist eine TLS-Prüfung erforderlich: Secure Web Proxy-Richtlinien können ausgehenden Traffic nur nach IP-Adresse filtern, es sei denn, die TLS-Prüfung ist aktiviert.
Workload Identity: GKE Ambient Networking unterstützt Standard-Workload Identity. Verwaltete Agentenidentitätspools werden für diese Vorabversion nicht unterstützt.
Authentifizierung: Bei der Verbindung zwischen dem Ambient-Knotenproxy und dem Secure Web Proxy wird die Überprüfung des Serverzertifikats übersprungen. Die CONNECT-Anfrage enthält neben dem Clientzertifikat ein ungebundenes Token.
Ressourcen bei Konfigurationsupdates neu erstellen: Änderungen an einer vorhandenen Secure Web Proxy-Instanz oder PSC-Konfiguration werden nicht automatisch übernommen. Wenn Sie die Secure Web Proxy- oder PSC-Konfiguration aktualisieren, müssen Sie die GCPEgressPolicy-Ressource und die Secure Web Proxy-Instanz löschen und neu erstellen, um die Änderungen zu übernehmen.
Trust-Anchor für die TLS-Prüfung: GKE fügt das private CA-Zertifikat von Secure Web Proxy nicht automatisch in Arbeitslastcontainer ein. Wenn Sie die TLS-Prüfung verwenden, müssen Sie das Vertrauenszertifikat manuell in Ihren Container-Images installieren.

Vorbereitung

Bevor Sie das Routing für ausgehenden Traffic konfigurieren, prüfen Sie, ob Sie Folgendes haben:

Einen GKE-Cluster mit aktiviertem Ambient Networking. Eine Anleitung finden Sie unter GKE Ambient Networking vorbereiten.
Eine bereitgestellte Secure Web Proxy-Instanz mit einer serverTlsPolicy, die mit clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT in IhremGoogle Cloud -Projekt oder Ihrer gemeinsam genutzten VPC konfiguriert ist.
Wenn sich der Secure Web Proxy in einem anderen VPC-Netzwerk als Ihr GKE-Cluster befindet:
- Ein PSC-Dienstanhang, der für den Secure Web Proxy erstellt wurde.
- Ein PSC-Nutzerendpunkt, der im VPC-Netzwerk Ihres GKE-Cluster konfiguriert ist.

Für diese Schritte benötigen Sie die folgenden Rollen:

Secure Web Proxy / Network Services: networkservices.gateways.* (oder roles/networkservices.admin) zum Konfigurieren von Secure Web Proxy-Gateway-Ressourcen.
PSC-Verwaltung (nur VPC-übergreifende Bereitstellungen): compute.networkAttachments.list (oder roles/compute.networkAdmin) zum Verwalten von Private Service Connect-Verbindungen.
GKE-Verwaltung: roles/container.clusterAdmin zum Bereitstellen benutzerdefinierter Ressourcen (GCPBackend, GCPEgressPolicy).

Vertrauen für die TLS-Prüfung konfigurieren

Wenn Ihre Secure Web Proxy-Richtlinie die TLS-Prüfung verwendet, um verschlüsselten ausgehenden Traffic zu prüfen, generiert der Proxy Zertifikate, die von seiner privaten Zertifizierungsstelle (Certificate Authority, CA) signiert wurden, um externe Ziele zu imitieren.

Ihre Arbeitslastanwendung muss dem privaten CA-Zertifikat vertrauen, das vom Secure Web Proxy bereitgestellt wird. Da GKE dieses Zertifikat nicht automatisch einfügt, müssen Sie das SWP-CA-Zertifikat (Trust-Anchor) im Trust Store Ihres Containers installieren.

Fügen Sie die folgenden Zeilen in Ihr Dockerfile ein, um das CA-Zertifikat Ihrem Container-Image hinzuzufügen:

COPY swp-ca-cert.pem /usr/local/share/ca-certificates/swp-ca-cert.crt
RUN update-ca-certificates

Gateway-Endpunkt definieren

Der erste Schritt beim Konfigurieren des Ambient-Egress-Routings besteht darin, einen Gateway-Endpunkt zu erstellen. Dieser definiert den Secure Web Proxy-Endpunkt in Ihrem GKE-Cluster und informiert Ambient Networking über den Standort des Proxys.

Wenn Sie den URI Ihres Secure Web Proxy- oder Private Service Connect-Dienstanhangs (PSC) angeben möchten, erstellen Sie eine benutzerdefinierte GCPBackend-Ressource in Ihrem GKE-Cluster:

Gleiche VPC

Speichern Sie das folgende Manifest als swp-backend.yaml:
```
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: swp-backend
  namespace: ambient-test
spec:
  serviceUris:
  - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SWP_NAME
```
Ersetzen Sie Folgendes:
- ambient-test: der Namespace, der für Ambient Networking registriert ist.
- PROJECT_ID: Projekt-ID in Google Cloud .
- REGION: die Region, in der Ihr Secure Web Proxy bereitgestellt wird.
- SWP_NAME: der Name Ihres Secure Web Proxy.
Wenden Sie die Ressource GCPBackend an:
```
kubectl apply -f swp-backend.yaml
```

VPC-übergreifend

Speichern Sie das folgende Manifest als swp-backend.yaml:
```
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: swp-backend
  namespace: ambient-test
spec:
  serviceUris:
  - //compute.googleapis.com/projects/PROJECT_ID/regions/REGION/serviceAttachments/ATTACHMENT_NAME
```
Ersetzen Sie Folgendes:
- ambient-test: der Namespace, der für Ambient Networking registriert ist.
- PROJECT_ID: Projekt-ID in Google Cloud .
- REGION: die Region, in der Ihr PSC-Dienstanhang bereitgestellt wird.
- ATTACHMENT_NAME: der Name Ihres PSC-Dienstanhangs, wenn sich Ihr Secure Web Proxy in einem anderen VPC-Netzwerk befindet.
Wenden Sie die Ressource GCPBackend an:
```
kubectl apply -f swp-backend.yaml
```

Weiterleitung von ausgehendem Traffic konfigurieren

Erstellen Sie eine benutzerdefinierte GCPEgressPolicy-Ressource, um ausgehenden Traffic vom Namespace zum Secure Web Proxy-Gateway weiterzuleiten. Dadurch wird die Signalisierung bereitgestellt, die der Ambient-Knotenproxy benötigt, um einen HTTP CONNECT-Tunnel zum Secure Web Proxy einzurichten, der für das ausgehende Routing erforderlich ist.

Speichern Sie das folgende Manifest als swp-egress-policy.yaml:
```
apiVersion: networking.gke.io/v1
kind: GCPEgressPolicy
metadata:
  name: swp-egress-policy
  namespace: ambient-test
spec:
  to:
    excludeCIDRRanges:
    - "CLUSTER_CONTROL_PLANE_CIDR"
  proxyRef:
    group: networking.gke.io
    kind: GCPBackend
    name: swp-backend
```
Ersetzen Sie Folgendes:
- ambient-test: Der Namespace, der für Ambient Networking registriert ist.
- CLUSTER_CONTROL_PLANE_CIDR: Der CIDR-Bereich für die interne Kommunikation, die den Secure Web Proxy umgehen soll (z. B. der Adressbereich der GKE-Steuerungsebene oder interne VPC-Subnetze).
Wenden Sie die Ressource GCPEgressPolicy an:
```
kubectl apply -f swp-egress-policy.yaml
```
Nachdem die Richtlinie angewendet wurde, wird ausgehender Traffic von Arbeitslasten im Namespace an den Secure Web Proxy weitergeleitet.

Fehlerbehebung

Verwenden Sie die folgende Anleitung, um Probleme mit dem Ambient-Routing für ausgehenden Traffic zu diagnostizieren und zu beheben:

Traffic erreicht den Secure Web Proxy nicht:
- Prüfen Sie bei Bereitstellungen in derselben VPC, ob die Ressource GCPBackend auf den richtigen URI des Secure Web Proxy-Gateways verweist.
- Für VPC-übergreifende Bereitstellungen:
- Prüfen Sie, ob die Ressource GCPBackend auf den richtigen PSC-Dienstanhang-URI verweist.
- Prüfen Sie, ob der PSC-Endpunkt in der Producer-VPC eingerichtet und akzeptiert wurde.
- Prüfen Sie, ob excludeCIDRRanges in GCPEgressPolicy nicht versehentlich mit Ihrem Zieltraffic übereinstimmt.
mTLS-Verbindungsfehler:
- Prüfen Sie, ob der Secure Web Proxy so konfiguriert ist, dass er Verbindungen vom Knotenproxy akzeptiert.
Fehler bei TLS-Prüfungszertifikaten:
- Wenn Clientanfragen mit Zertifikatsvalidierungsfehlern (z. B. x509: certificate signed by unknown authority) fehlschlagen, prüfen Sie, ob das CA-Zertifikat des Secure Web Proxy ordnungsgemäß im Systemzertifikatspeicher des Arbeitslastcontainers installiert ist.