Auf dieser Seite erfahren Sie, wie Sie Ambient Networking in einem neuen oder vorhandenen Cluster aktivieren, Namespaces und Arbeitslasten registrieren, um die Ambient-Traffic-Umleitung zu aktivieren, und mTLS- und Autorisierungsrichtlinien konfigurieren.
Weitere Informationen zur Ambient-Networking-Architektur, zu den Vorteilen und Funktionen finden Sie in der Übersicht zu Ambient Networking.
Voraussetzungen und Einschränkungen
Bevor Sie Ambient Networking einrichten, sollten Sie sich die folgenden Einschränkungen der Funktion, Versionsanforderungen und Bereichseinschränkungen ansehen:
- GKE-Version:Erfordert GKE-Version
1.35.2-gke.1842000oder höher. - Regionale Unterstützung:Cluster müssen in einer Region erstellt werden, die von Regional Cloud Service Mesh unterstützt wird.
- Interoperabilität von Arbeitslasten:Arbeitslasten, die für Ambient Networking registriert sind, können nicht mit Sidecar-eingefügten Arbeitslasten oder proxylosen gRPC-Arbeitslasten in der privaten Vorabversion zusammenarbeiten.
- Nicht unterstützte Funktionen:
- Feld „Kubernetes Service“
trafficDistribution. - Monitorlose Dienste
- GKE Sandbox (gVisor)
- Feld „Kubernetes Service“
- Sicherheitshinweis:Wenn die
gke-ambient-nriplugin-Komponente auf einem Knoten nicht mehr verfügbar ist, kann die Authentifizierung und Autorisierung von eingehendem Traffic umgangen werden.
Hinweis
Führen Sie die folgenden Einrichtungsschritte in Google Cloudaus:
- Erstellen Sie ein Projekt oder wählen Sie eines aus.
Aktivieren Sie die erforderlichen APIs:
gcloud services enable \ privateca.googleapis.com \ gkehub.googleapis.com \ compute.googleapis.com \ container.googleapis.com \ trafficdirector.googleapis.com \ networkservices.googleapis.com \ networksecurity.googleapis.com \ telemetry.googleapis.com \ monitoring.googleapis.com \ logging.googleapis.comAuthentifizierung von verwalteten Arbeitslastidentitäten für GKE konfigurieren
Ambient Networking in einem neuen Cluster aktivieren
Führen Sie den folgenden Befehl aus, um einen neuen GKE-Cluster mit aktivierter Ambient-Vernetzung zu erstellen:
GKE-Cluster mit aktiviertem Ambient Networking erstellen
gcloud beta container clusters create CLUSTER_NAME \ --machine-type=e2-standard-4 \ --enable-ambient-networking \ --enable-dataplane-v2 \ --enable-fleet \ --gateway-api=standard \ --location=CLUSTER_LOCATION \ --release-channel=rapid \ --workload-pool=PROJECT_ID.svc.id.googIm Namespace
gke-managed-ambientwerden jetzt zwei DaemonSets ausgeführt.
Ambient Networking für einen vorhandenen Cluster aktivieren
So aktivieren Sie Ambient Mesh in einem vorhandenen GKE-Cluster:
Prüfen Sie, ob Ihr Cluster die folgenden Anforderungen erfüllt:
- Version 1.35.2-gke.1842000 oder höher.
- GKE Dataplane V2 aktiviert.
- Der Maschinentyp muss e2-standard-4 oder höher sein.
- Der Cluster muss einer Flotte hinzugefügt werden.
- Im Cluster müssen die Gateway API und Workload Identity aktiviert sein.
Ambient Networking für einen vorhandenen Cluster aktivieren:
gcloud beta container clusters update CLUSTER_NAME \ --enable-ambient-networking \ --location=CLUSTER_LOCATION \ --enable-fleetIm Namespace
gke-managed-ambientwerden jetzt zwei DaemonSets ausgeführt.Um dies zu überprüfen, richten Sie die CLI auf den Cluster aus:
gcloud beta container clusters get-credentials CLUSTER_NAME \ --location=CLUSTER_LOCATIONRufen Sie die DaemonSets im Namespace
gke-managed-ambientab:kubectl get daemonset -n gke-managed-ambientDie Ausgabe sieht etwa so aus:
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE AGE gke-ambient-nriplugin 9 9 9 9 9 4d1h gke-ambient-proxy 9 9 9 9 9 4d1h
Namespace für Ambient Networking registrieren
So stellen Sie eine Beispielanwendung bereit und aktivieren die Umleitung von Ambient-Traffic für ihren Namespace:
Beispielanwendung bereitstellen:
kubectl apply -f - <<EOF apiVersion: v1 kind: Namespace metadata: name: ambient-test --- apiVersion: v1 kind: ServiceAccount metadata: name: client namespace: ambient-test --- apiVersion: v1 kind: ServiceAccount metadata: name: server namespace: ambient-test --- apiVersion: v1 kind: Service metadata: name: server namespace: ambient-test labels: app: server spec: ports: - port: 80 protocol: TCP selector: app: server --- apiVersion: apps/v1 kind: Deployment metadata: name: client namespace: ambient-test labels: app: client spec: replicas: 1 selector: matchLabels: app: client template: metadata: labels: app: client spec: serviceAccountName: client containers: - name: nginx image: nginx:1.29.6 --- apiVersion: apps/v1 kind: Deployment metadata: name: server namespace: ambient-test labels: app: server spec: replicas: 2 selector: matchLabels: app: server template: metadata: labels: app: server spec: serviceAccountName: server containers: - name: nginx image: nginx:1.29.6 readinessProbe: httpGet: path: / port: 80 EOFFügen Sie dem
ambient-test-Namespace ein Label hinzu, um die Weiterleitung von Traffic über den Ambient-Proxy von GKE zu aktivieren:kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambientPrüfen Sie, ob einzelne Pods im Namespace für die Umleitung von Traffic konfiguriert wurden:
kubectl get pods -n ambient-test -o yaml | grep redirectionDie Ausgabe sieht etwa so aus:
ambient.networking.gke.io/redirection: enabled ambient.networking.gke.io/redirection: enabledClient-zu-Server-Traffic testen:
kubectl exec -it deploy/client -n ambient-test -- \ /bin/curl -fsLS server.ambient-test.svc.cluster.localWenn Sie prüfen möchten, ob der Klartext-Traffic über
gke-ambient-proxyfließt, sehen Sie sich die Zugriffslogs im Log-Explorer an und suchen Sie nachgke-ambient-node-proxy-accesslog:Optional: Aktivieren Sie die Generierung von Layer 4-Messwerten für Arbeitslasten im Namespace:
kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabledNach der Aktivierung sind Arbeitslastmesswerte in Cloud Monitoring über Network Services Monitoring verfügbar.
mTLS für einen Dienst aktivieren
Nachdem Sie die Traffic-Umleitung für Arbeitslasten in einem Namespace aktiviert haben, wenden Sie Richtlinien an, um Verschlüsselung, Authentifizierung und Autorisierung zu erzwingen.
Konfigurieren Sie eine permissive mTLS-Richtlinie für die serverseitigen Arbeitslasten:
kubectl apply -f - <<EOF apiVersion: networking.gke.io/v1 kind: GCPServerTLSPolicy metadata: name: server namespace: ambient-test spec: mtlsMode: Permissive targetRefs: - group: "" kind: Pod selector: matchLabels: app: server EOFMit dieser Richtlinie akzeptieren die Pods sowohl mTLS- als auch Klartext-Traffic. Bei permissivem mTLS wird der Traffic analysiert, um zu erkennen, ob es sich um mTLS- oder Klartext-Traffic handelt. Dadurch wird der Anwendungs-Traffic unterbrochen, der ein eigenes TLS- oder ein „Server spricht zuerst“-Protokoll wie MySQL verwendet.
Prüfen Sie, ob die Richtlinie vom Controller akzeptiert wurde:
kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 StatusDie Ausgabe sieht etwa so aus:
[...] Conditions: Last Transition Time: 2026-03-25T17:47:30Z Message: Reason: Accepted Status: True Type: Accepted Controller Name: networking.gke.io/dpv2-1n Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 108s (x2 over 2m20s) sc-dpv2-1n-controller Sync on Mesh dpv2-1n-fqtx-mesh succeededDie Weitergabe von Richtlinien kann nach der Controller-Akzeptanz bis zu drei Minuten dauern. Warten Sie drei Minuten, bevor Sie fortfahren.
Konfigurieren Sie eine clientseitige mTLS-Richtlinie, die auf den Dienst ausgerichtet ist:
kubectl apply -f - <<EOF apiVersion: networking.gke.io/v1 kind: GCPClientTLSPolicy metadata: name: server-mtls namespace: ambient-test spec: targetRefs: - group: "" kind: Service name: server subjectAltNames: - uri: spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/server EOFMit dieser Richtlinie werden registrierte Clients so konfiguriert, dass sie mTLS-Traffic an den Serverdienst senden. Möglicherweise musst du mindestens zwei Minuten warten, bevor du mit dem nächsten Schritt fortfahren kannst.
Prüfen Sie, ob die Richtlinie vom Controller akzeptiert wurde:
kubectl describe gcpclienttlspolicies -n ambient-test server-mtls | grep -A50 StatusDie Ausgabe sieht etwa so aus:
[...] Status: Conditions: Last Transition Time: 2024-10-13T01:15:03Z Message: Observed Generation: 1 Reason: Accepted Status: True Type: AcceptedClient-zu-Server-Traffic testen:
kubectl exec -it deploy/client -n ambient-test -- \ /bin/curl -fsLS server.ambient-test.svc.cluster.localDer Traffic von Pods, die für Ambient Networking registriert sind, zum Serverdienst im Namespace „ambient-test“ sollte jetzt mTLS verwenden.
Um zu prüfen, ob Verbindungen mTLS verwenden, sehen Sie sich die Zugriffslogs im Log-Explorer an und suchen Sie nach dem benutzerdefinierten Log-Namen:
Aktualisieren Sie die vorhandene GCPServerTLSPolicy, um die
modedes Serverdienstes von Permissive in Strict zu ändern, damit die Arbeitslast-Pods keinen Nur-Text-Traffic mehr akzeptieren:kubectl apply -f - <<EOF apiVersion: networking.gke.io/v1 kind: GCPServerTLSPolicy metadata: name: server namespace: ambient-test spec: mtlsMode: Strict targetRefs: - group: "" kind: Pod selector: matchLabels: app: server EOFPrüfen Sie, ob die Richtlinie akzeptiert wurde:
kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 StatusDie Ausgabe sieht etwa so aus:
Name: server <...> UID: e4f2a7a3-69aa-4528-8ea6-6f1bf2142011 Spec: Mtls Mode: Strict Target Refs: Group: Kind: Pod Selector: Match Labels: App: server Status: Ancestors: Ancestor Ref: Group: Kind: Pod Name: app=server Conditions: Last Transition Time: 2026-03-25T22:33:54Z Message: Reason: Accepted Status: True Type: Accepted Controller Name: networking.gke.io/dpv2-1n Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 43s (x5 over 4m57s) sc-dpv2-1n-controller Sync on Mesh dpv2-1n-2cdi-mesh succeededDer gesamte unverschlüsselte Traffic zu Ihrem Serverdienst wird jetzt abgelehnt.
Um zu prüfen, ob Klartext-Traffic jetzt abgelehnt wird, senden Sie Traffic vom Serverdienst an einen Client, der NICHT für Ambient Networking registriert ist:
kubectl create namespace noambient-test && \ kubectl run -it -n noambient-test --rm curl --image=nginx -- \ /bin/curl -fsLSv http://server.ambient-test.svc.cluster.localDiese Verbindung sollte mit einer Meldung wie der folgenden fehlschlagen:
* Request completely sent off * Empty reply from server * shutting down connection #0 curl: (52) Empty reply from server
Autorisierungsrichtlinie für Schicht 4 festlegen
Um die identitätsbasierte Autorisierung zu erzwingen, geben Arbeitslastinhaber Pod-Labels im Richtlinienselektor an. Namespace-Inhaber wenden Richtlinien namespaceweit ohne Selektoren an.
Wenden Sie die folgende Richtlinie an, um zu erzwingen, dass nur der Client mit dem Server kommunizieren darf:
kubectl apply -f - <<EOF apiVersion: networking.gke.io/v1 kind: GCPAuthzPolicy metadata: name: allow-client namespace: ambient-test spec: action: ALLOW enforcementLevel: L4 targetRefs: - group: "" kind: Pod selector: matchLabels: app: server rules: - from: sources: - principals: - principalSelector: CLIENT_CERT_URI_SAN principal: type: Exact value: spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/client EOFDiese Richtlinie wird für Traffic zu Server-Pods im Namespace
ambient-testerzwungen. Dadurch wird sichergestellt, dass Traffic nur von Quellen mit der SPIFFE-Identität spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/client zugelassen wird.Prüfen Sie, ob die Richtliniendurchsetzung zulässig ist, indem Sie eine Beispielanfrage vom Dienstkonto des Clients senden.
kubectl exec -it deploy/client -n ambient-test -- \ /bin/curl -fsLS server.ambient-test.svc.cluster.localPrüfen Sie, ob die Richtlinienerzwingung nicht zulässig ist, indem Sie eine Beispielanfrage vom Dienstkonto des Servers senden.
kubectl exec -it deploy/server -n ambient-test -- \ /bin/curl -fsLS server.ambient-test.svc.cluster.localDie Ausgabe sieht etwa so aus:
curl: (52) Empty reply from server command terminated with exit code 52Mit dem Log-Explorer können Sie das Logging der Autorisierungserzwingung aufrufen. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.