Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

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 Egress-Routing für Arbeitslasten konfigurieren, die in der Ambient-Netzwerkumgebung von Google Kubernetes Engine (GKE) zu einem Secure Web Proxy-Gateway (SWP) ausgeführt werden.

Wenn Sie ausgehenden Traffic über ein Secure Web Proxy-Gateway weiterleiten, können Sie zentralisierte Richtlinien für ausgehenden Traffic erzwingen, z. B. URL-Filterung, Zulassungslisten für Domains 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 wird.

Architektur und Trafficfluss

Bei diesem Bereitstellungsmodell sind Sie Eigentümer der Infrastruktur, einschließlich des GKE-Cluster, der Secure Web Proxy-Instanz und aller Private Service Connect-Endpunkte.

Der Traffic-Fluss für ausgehenden Traffic funktioniert so:

Ein Pod für eine Arbeitslast oder einen KI-Agenten initiiert ausgehenden Traffic zu einem externen Endpunkt oder Internetziel.
Der lokale Ambient-Node-Proxy der Schicht 4 fängt die ausgehende Anfrage auf dem Knoten ab.
Der Knotenproxy stellt einen HTTP-CONNECT-Tunnel zum Egress-Gateway her.
Wenn sich der Secure Web Proxy in einem anderen VPC-Netzwerk befindet, wird der Traffic über einen PSC-Dienstanhang weitergeleitet.
Der Secure Web Proxy beendet den Tunnel, erzwingt die konfigurierten Sicherheitsrichtlinien für ausgehenden Traffic und leitet autorisierte Anfragen an das Ziel weiter.

Beschränkungen

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

Namespace-weite Richtlinien:Richtlinien für ausgehenden Traffic werden nur auf Namespace-Ebene angewendet. Die detaillierte Pod-Auswahl mithilfe von Label-Selektoren wird nicht unterstützt.
Für die Hostnamensfilterung ist die TLS-Prüfung erforderlich:Secure Web Proxy-Richtlinien können ausgehenden Traffic nur nach IP-Adresse filtern, wenn die TLS-Prüfung aktiviert ist.
Workload Identity:GKE Ambient Networking unterstützt die Standard-Workload Identity. Verwaltete Agent Identity-Pools werden für diese Vorabversion nicht unterstützt.
Authentifizierung:Bei der Verbindung zwischen dem Ambient-Knoten-Proxy und dem Secure Web Proxy wird die Serverzertifikatsprüfung übersprungen. Die CONNECT-Anfrage enthält neben dem Clientzertifikat ein ungebundenes Token.
Ressourcenneuerstellung bei Konfigurationsupdates:Änderungen an einer vorhandenen Secure Web Proxy-Instanz oder PSC-Konfiguration werden nicht automatisch weitergegeben. Wenn Sie Ihre Secure Web Proxy- oder PSC-Konfiguration aktualisieren, müssen Sie die GCPEgressPolicy-Ressource und die Secure Web Proxy-Instanz löschen und neu erstellen, damit die Änderungen übernommen werden.
TLS-Prüfungs-Trust-Anchor: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

Prüfen Sie vor dem Konfigurieren des Egress-Routings, ob die folgenden Voraussetzungen erfüllt sind:

Ein GKE-Cluster mit aktiviertem Ambient Networking. Eine Anleitung finden Sie unter GKE-Ambient-Networking vorbereiten.
Eine bereitgestellte Secure Web Proxy-Instanz mit einem serverTlsPolicy, das mit clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT in IhremCloud de Confiance by S3NS -Projekt oder der 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 in Ihrem GKE-Cluster-VPC-Netzwerk konfiguriert ist.

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

KI-Agenten-Gateway / Netzwerkdienste: networkservices.agentGateways.* (oder roles/networkservices.admin) zum Konfigurieren von KI-Agenten-Gateway-Ressourcen.
PSC-Verwaltung: 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 in Ihrer Secure Web Proxy-Richtlinie die TLS-Prüfung verwendet wird, um verschlüsselten ausgehenden Traffic zu prüfen, generiert der Proxy Zertifikate, die von seiner privaten Zertifizierungsstelle (Certificate Authority, CA) signiert sind, um externe Ziele zu imitieren.

Ihre Arbeitslastanwendung muss dem privaten CA-Zertifikat vertrauen, das vom sicheren Web-Proxy präsentiert wird. Da dieses Zertifikat nicht automatisch in GKE eingefügt wird, müssen Sie das SWP-Zertifizierungsstellenzertifikat (Trust Anchor) im Trust Store Ihres Containers installieren.

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

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 das Ambient-Netzwerk ü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 GCPBackend-Benutzerressource in Ihrem GKE-Cluster:

Speichern Sie das folgende Manifest als swp-backend.yaml:

Gleiche VPC
```
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 Cloud de Confiance by S3NS .
- REGION: die Region, in der Ihr Secure Web Proxy oder PSC-Dienstanhang bereitgestellt wird.
- SWP_NAME: Der Name Ihres sicheren Web-Proxys.
VPC-übergreifend
```
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 Cloud de Confiance by S3NS .
- REGION: die Region, in der Ihr Secure Web Proxy oder PSC-Dienstanhang bereitgestellt wird.
- ATTACHMENT_NAME: der Name Ihrer PSC-Service-Attachment, wenn sich Ihr Secure Web Proxy in einem anderen VPC-Netzwerk befindet.
Wenden Sie die Ressource GCPBackend an:
```
kubectl apply -f swp-backend.yaml
```

Umleitung des ausgehenden Traffics konfigurieren

Erstellen Sie eine benutzerdefinierte GCPEgressPolicy-Ressource, um ausgehenden Traffic aus dem Namespace an das Secure Web Proxy-Gateway weiterzuleiten. Dadurch wird die Signalisierung bereitgestellt, die für den Ambient-Knoten-Proxy erforderlich ist, um einen HTTP-CONNECT-Tunnel zum sicheren Webproxy herzustellen, was für das Egress-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 der ausgehende Traffic von Arbeitslasten im Namespace an den sicheren Web-Proxy weitergeleitet.

Fehlerbehebung

Mit den folgenden Hinweisen können Sie Probleme mit dem Ambient-Egress-Routing diagnostizieren und beheben:

Traffic erreicht den sicheren Web-Proxy nicht:
- Prüfen Sie, ob die GCPBackend-Ressource auf den richtigen PSC-Dienstanhang-URI verweist.
- Prüfen Sie, ob der PSC-Endpunkt eingerichtet und in der Producer-VPC akzeptiert wurde.
- Prüfen Sie, ob excludeCIDRRanges in GCPEgressPolicy versehentlich mit Ihrem Ziel-Traffic übereinstimmt.
Fehler bei mTLS-Verbindungen:
- Prüfen Sie, ob der sichere Web-Proxy so konfiguriert ist, dass er Verbindungen vom Knoten-Proxy akzeptiert.
TLS-Prüfungszertifikatsfehler:
- Wenn Clientanfragen mit Zertifikatvalidierungsfehlern (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.