Prepara il networking ambient di GKE

Autopilot Standard

Anteprima

Questo prodotto o funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Nota: prima di utilizzare GKE ambient networking, devi essere aggiunto a una lista consentita. Richiedi l'accesso alla lista consentita compilando il modulo di registrazione.

Questa pagina mostra come abilitare il networking ambientale su un cluster nuovo o esistente, registrare spazi dei nomi e workload per abilitare il reindirizzamento del traffico ambientale e configurare mTLS e le norme di autorizzazione.

Per saperne di più sull'architettura, sui vantaggi e sulle funzionalità del networking ambientale, consulta la Panoramica del networking ambientale.

Prerequisiti e limitazioni

Prima di configurare la rete per l'ambiente, esamina le seguenti limitazioni delle funzionalità, i requisiti di versione e le limitazioni dell'ambito:

• Versione GKE:richiede GKE versione 1.35.2-gke.1842000 o 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 sidecar inserito o gRPC senza proxy in anteprima privata.
• Funzionalità non supportate:
  • Campo trafficDistribution del servizio Kubernetes.
  • Servizi headless.
  • GKE Sandbox (gVisor).
• Avviso di sicurezza: se il componente gke-ambient-nriplugin non è più disponibile su un nodo, l'applicazione dell'autenticazione e dell'autorizzazione del traffico in entrata potrebbe essere bypassata.

Prima di iniziare

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

1. Crea o seleziona un progetto.

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

3. Configura l'autenticazione dell'identità del workload gestita per GKE.

Abilitare il networking ambientale su un nuovo cluster

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

1. Crea un cluster GKE con la funzionalità di rete ambient abilitata

   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 due DaemonSet vengono eseguiti nello spazio dei nomi gke-managed-ambient.

Abilita il networking ambientale su un cluster esistente

Segui questi passaggi per abilitare Ambient Mesh su un cluster GKE esistente:

1. Verifica che il cluster soddisfi i seguenti requisiti:

   • Versione 1.35.2-gke.1842000 o successiva.
   • 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 abilitati l'API Gateway e Workload Identity.

2. Abilita il networking ambientale su un cluster esistente:

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

   Ora due DaemonSet vengono eseguiti nello spazio dei nomi gke-managed-ambient.

3. Per verificare, indirizza la CLI al cluster:

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

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

Registrare 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 ambientale nel relativo spazio dei nomi:

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

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

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

4. Testa il traffico dal client al server:

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

5. Per verificare che il traffico in testo non crittografato scorra attraverso gke-ambient-proxy, controlla i log di accesso in Esplora log e cerca gke-ambient-node-proxy-accesslog:

   Vai a Esplora log

6. (Facoltativo) Abilita la generazione di metriche di livello 4 per i carichi di lavoro 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 Network Services Monitoring.

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.

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

   Questo criterio fa in modo che i pod accettino sia il traffico mTLS che quello in testo non crittografato. Tieni presente che mTLS permissivo utilizza l'analisi del traffico per rilevare se il traffico è mTLS o in testo non crittografato. In questo modo, il traffico delle applicazioni che utilizza il proprio TLS o un protocollo "server speaks first" come MySQL verrà interrotto.

2. Verifica che la policy sia stata accettata dal titolare del trattamento:

   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 delle norme può richiedere fino a tre minuti dopo l'accettazione del controller. Attendi tre minuti prima di procedere.

3. 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 per generare traffico mTLS verso il servizio server. Potresti dover attendere almeno due minuti prima di procedere al passaggio successivo.

4. Verifica che la policy sia stata accettata dal titolare del trattamento:

   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
   

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

6. Per verificare che le connessioni utilizzino mTLS, controlla i log di accesso in Esplora log e cerca il nome del log personalizzato:

   Vai a Esplora log

7. Aggiorna il criterio GCPServerTLSPolicy esistente per modificare mode da Permissive a Strict sul servizio server in modo che i pod del carico di lavoro non accettino più il traffico in testo normale:

   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
   

8. 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 al servizio server verrà ora rifiutato.

9. Per verificare che il traffico in testo non crittografato venga ora rifiutato, invia 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 e mostrare 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 dello spazio dei nomi applicano le policy a livello di spazio dei nomi senza selettori.

1. Applica la seguente policy per imporre che solo al client sia consentito 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. Garantisce che il traffico sia consentito solo da origini con identità SPIFFE spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/client.

2. Verifica che l'applicazione dei criteri sia consentita inviando una richiesta di esempio dall'account di servizio client.

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

3. Verifica che l'applicazione dei criteri non sia consentita inviando una richiesta di esempio dall'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
   

4. Puoi utilizzare Esplora log per visualizzare il logging dell'applicazione dell'autorizzazione. Nella console Google Cloud , vai alla pagina Esplora log.

   Vai a Esplora log