Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Prepara il networking ambient di GKE

Autopilot Standard

Questa pagina mostra come abilitare Ambient Networking su un cluster nuovo o esistente, registrare spazi dei nomi e workload per abilitare il reindirizzamento del traffico ambient e configurare mTLS e policy di autorizzazione.

Per saperne di più sull'architettura, sui vantaggi e sulle funzionalità di Ambient Networking, consulta la panoramica di Ambient Networking.

Prerequisiti e limitazioni

Prima di configurare l'Ambient Networking, esamina le seguenti limitazioni delle funzionalità, i requisiti di versione e le restrizioni dell'ambito:

Versione GKE: richiede GKE 1.36.4-gke.1391000 o versioni successive.
Supporto regionale: i cluster devono essere creati in una regione supportata da Cloud Service Mesh regionale.
Interoperabilità dei workload: i workload registrati in Ambient Networking non possono interagire con i workload con iniezione sidecar o gRPC senza proxy in anteprima.
Funzionalità non supportate:
- Campo trafficDistribution del servizio Kubernetes.
- Servizi headless.
- GKE Sandbox (gVisor).
Avviso di sicurezza: se il componente gke-ambient-nriplugin non è disponibile su un nodo, l'applicazione dell'autenticazione e dell'autorizzazione del traffico in entrata potrebbe essere ignorata.

Prima di iniziare

Completa i seguenti passaggi di configurazione dei prerequisiti in Google Cloud:

Crea o seleziona un progetto.

Abilita le API richieste:

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.com

Configura l'autenticazione di Managed Workload Identity per GKE.

Abilita Ambient Networking su un nuovo cluster

Esegui questo comando per creare un nuovo cluster GKE con il networking Ambient abilitato:

Crea un cluster GKE con Ambient Networking abilitato

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.goog

Ora nello spazio dei nomi gke-managed-ambient sono in esecuzione due DaemonSet.

Abilita Ambient Networking su un cluster esistente

Segui questi passaggi per abilitare l'ambient mesh su un cluster GKE esistente:

Verifica che il cluster soddisfi i seguenti requisiti:
- Versione 1.36.4-gke.1391000 o successive.
- GKE Dataplane V2 abilitato.
- Il tipo di macchina deve essere e2-standard-4 o superiore.
- Il cluster deve essere aggiunto a un parco risorse.
- Nel cluster devono essere abilitate l'API Gateway e Workload Identity.

Abilita l'Ambient Networking su un cluster esistente:

gcloud beta container clusters update CLUSTER_NAME \
    --enable-ambient-networking \
    --location=CLUSTER_LOCATION \
    --enable-fleet

Ora nello spazio dei nomi gke-managed-ambient sono in esecuzione due DaemonSet.

Per verificare, indirizza l'interfaccia a riga di comando al cluster:

gcloud beta container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION

Recupera i daemonset nello spazio dei nomi gke-managed-ambient:

kubectl get daemonset -n gke-managed-ambient

L'output è simile al seguente:

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

Registra uno spazio dei nomi per Ambient Networking

Segui questi passaggi per eseguire il deployment di un'applicazione di esempio e attivare il reindirizzamento del traffico in modalità Ambient nel relativo spazio dei nomi:

Esegui il deployment di un'applicazione di esempio:

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
EOF

Etichetta lo spazio dei nomi ambient-test per attivare il reindirizzamento del traffico tramite il proxy GKE Ambient:
```
kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambient
```

Verifica che i singoli pod nello spazio dei nomi siano stati configurati per il reindirizzamento del traffico:

kubectl get pods -n ambient-test -o yaml | grep redirection

L'output è simile al seguente:

ambient.networking.gke.io/redirection: enabled
ambient.networking.gke.io/redirection: enabled

Testa il traffico dal client al server:

kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Per verificare che il traffico in testo non crittografato passi attraverso gke-ambient-proxy, controlla i log degli accessi in Esplora log e cerca il nome del log gke-ambient-node-proxy-accesslog:

Vai a Esplora log
Facoltativamente, abilita la generazione di metriche di livello 4 per i workload nello spazio dei nomi:
```
kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabled
```
Una volta abilitate, le metriche dei workload sono disponibili in Cloud Monitoring tramite Monitoraggio dei servizi di rete.

Abilita mTLS per un servizio

Dopo aver abilitato il reindirizzamento del traffico per i workload in uno spazio dei nomi, applica le policy per applicare la crittografia, l'autenticazione e l'autorizzazione.

Configura una policy mTLS permissiva sui workload lato server:
```
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
EOF
```
Questa policy fa sì che i pod accettino sia il traffico mTLS sia quello in testo non crittografato. Tieni presente che mTLS permissivo utilizza lo sniffing del traffico per rilevare se il traffico è mTLS o testo normale. In questo modo, il traffico dell'applicazione che utilizza il proprio TLS o un protocollo "server speaks first" come MySQL verrà interrotto.

Verifica che la policy sia stata accettata dal controller:

kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

L'output è simile al seguente:

[...]

    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 succeeded

La propagazione della policy può richiedere fino a tre minuti dopo l'accettazione del controller. Attendi tre minuti prima di procedere.

Configura una policy mTLS lato client che ha come target il servizio:

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
EOF

Questa policy configura i client registrati in modo che generino traffico mTLS verso il servizio server. Potresti dover attendere almeno due minuti prima di procedere con il passaggio successivo.

Verifica che la policy sia stata accettata dal controller:

kubectl describe gcpclienttlspolicies -n ambient-test server-mtls | grep -A50 Status

L'output è simile al seguente:

[...]
Status:
Conditions:
    Last Transition Time:  2024-10-13T01:15:03Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted

Testa il traffico dal client al server:
```
kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
Il traffico dai pod registrati in Ambient Networking al servizio server nello spazio dei nomi ambient-test ora dovrebbe utilizzare mTLS.
Per verificare che le connessioni utilizzino mTLS, controlla i log di accesso in Esplora log e cerca il nome del log gke-ambient-node-proxy-accesslog:

Vai a Esplora log

Aggiorna la risorsa GCPServerTLSPolicy esistente per modificare mode da Permissive a Strict sul servizio server in modo che i pod del workload non accettino più il traffico in testo non crittografato:

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
EOF

Verifica che la policy sia stata accettata:

kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

L'output è simile al seguente:

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 succeeded

Qualsiasi traffico in testo non crittografato verso il servizio server verrà ora rifiutato.

Per verificare che il traffico in testo non crittografato venga ora rifiutato, invia il traffico al servizio server da un client NON registrato in Ambient Networking:

kubectl create namespace noambient-test && \
kubectl run -it -n noambient-test --rm curl --image=nginx -- \
    /bin/curl -fsLSv http://server.ambient-test.svc.cluster.local

Questa connessione dovrebbe non riuscire con un messaggio simile al seguente:

* Request completely sent off
* Empty reply from server
* shutting down connection #0
curl: (52) Empty reply from server

Imposta la policy di autorizzazione di livello 4

Per applicare l'autorizzazione basata sull'identità, i proprietari dei workload specificano le etichette dei pod nel selettore delle policy. I proprietari degli spazi dei nomi applicano le policy a livello di spazio dei nomi senza selettori.

Applica la seguente policy per imporre che solo il client possa comunicare con il server:

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
EOF

Questa policy viene applicata al traffico verso i pod server nello spazio dei nomi ambient-test. In questo modo, il traffico è consentito solo da origini con identità SPIFFE spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/client.

Verifica che l'applicazione delle policy sia consentita inviando una richiesta di esempio dal account di servizio client.

kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Verifica che l'applicazione delle policy non sia consentita inviando una richiesta di esempio dal account di servizio server.

kubectl exec -it deploy/server -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

L'output è simile al seguente:

curl: (52) Empty reply from server
command terminated with exit code 52

Puoi utilizzare Esplora log per visualizzare il logging dell'applicazione dell'autorizzazione. Nella console Google Cloud , vai alla pagina Esplora log e cerca le richieste rifiutate utilizzando il nome del log gke-ambient-node-proxy-accesslog:
```
resource.type="k8s_container"
logName="projects/PROJECT_ID/logs/gke-ambient-node-proxy-accesslog"
jsonPayload.error_details=~"rbac_access_denied"
```
Vai a Esplora log

Prepara il networking ambient di GKE Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prerequisiti e limitazioni

Prima di iniziare

Abilita Ambient Networking su un nuovo cluster

Abilita Ambient Networking su un cluster esistente

Registra uno spazio dei nomi per Ambient Networking

Abilita mTLS per un servizio

Imposta la policy di autorizzazione di livello 4

Prepara il networking ambient di GKE