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

Instradare il traffico in uscita ambientale tramite Secure Web Proxy

Autopilot Standard

Questa pagina mostra come configurare il routing in uscita per i workload in esecuzione sul networking Ambient di Google Kubernetes Engine (GKE) su un gateway Secure Web Proxy (SWP).

Se instradi il traffico in uscita tramite un gateway Secure Web Proxy, puoi applicare policy di sicurezza in uscita centralizzate, come il filtro degli URL, le liste consentite di domini e l'ispezione TLS, senza modificare il codice dell'applicazione. Il proxy del nodo di livello 4 intercetta il traffico in uscita al di fuori del pod dell'applicazione, fornendo un isolamento di sicurezza out-of-pod anche se un container del workload è compromesso.

Architettura e flusso del traffico

In questo modello di deployment, mantieni la proprietà dell'infrastruttura, inclusi il cluster GKE, l'istanza Secure Web Proxy e tutti gli endpoint Private Service Connect (PSC) (per i deployment tra VPC).

Il flusso del traffico in uscita funziona nel seguente modo:

Un pod del workload avvia il traffico in uscita verso un endpoint esterno o una destinazione internet.
Il proxy del nodo ambient di livello 4 locale intercetta la richiesta in uscita sul nodo.
Il proxy del nodo stabilisce un tunnel HTTP CONNECT verso il gateway in uscita.
Se Secure Web Proxy si trova nella stessa rete VPC, il traffico si connette direttamente al gateway. Se Secure Web Proxy risiede in una rete VPC diversa, il traffico attraversa un collegamento al servizio PSC.
Secure Web Proxy termina il tunnel, applica le policy di sicurezza in uscita configurate e inoltra le richieste autorizzate alla destinazione.

Limitazioni

Prima di configurare il routing in uscita di Secure Web Proxy, esamina le seguenti limitazioni in anteprima:

Policy a livello di spazio dei nomi: le policy di routing in uscita si applicano solo a livello di spazio dei nomi. La selezione granulare dei pod tramite selettori di etichette non è supportata.
Il filtro dei nomi host richiede l'ispezione TLS: le policy di Secure Web Proxy possono filtrare il traffico in uscita solo in base all'indirizzo IP, a meno che non sia abilitata l'ispezione TLS.
Workload Identity: il networking Ambient di GKE supporta Workload Identity standard. I pool di identità degli agenti gestiti non sono supportati per questa anteprima.
Autenticazione: la connessione tra il proxy del nodo ambient e Secure Web Proxy ignora la verifica del certificato del server. La richiesta CONNECT include un token non limitato insieme al certificato client.
Ricreazione delle risorse in caso di aggiornamenti della configurazione: le modifiche apportate a un'istanza Secure Web Proxy o a una configurazione PSC esistente non vengono propagate automaticamente. Se aggiorni la configurazione di Secure Web Proxy o PSC, devi eliminare e ricreare la risorsa GCPEgressPolicy e l'istanza di Secure Web Proxy per applicare le modifiche.
Trust anchor per l'ispezione TLS: GKE non inserisce automaticamente il certificato CA privato di Secure Web Proxy nei container dei workload. Se utilizzi l'ispezione TLS, devi installare manualmente il certificato di attendibilità nelle immagini container.

Prerequisiti

Prima di configurare il routing in uscita, verifica di disporre di quanto segue:

Un cluster GKE con Ambient Networking abilitato. Per istruzioni, consulta Prepara GKE Ambient Networking.
Un'istanza di Secure Web Proxy di cui è stato eseguito il deployment con unserverTlsPolicy configurato conclientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT nel tuo progetto o VPC condivisoGoogle Cloud .
Se Secure Web Proxy si trova in una rete VPC diversa da quella del tuo cluster GKE:
- Un collegamento al servizio PSC creato per Secure Web Proxy.
- Un endpoint consumer PSC configurato nella rete VPC del cluster GKE.

Per completare questi passaggi, devi disporre dei seguenti ruoli:

Secure Web Proxy/Network Services: networkservices.gateways.* (o roles/networkservices.admin) per configurare le risorse del gateway Secure Web Proxy.
Gestione PSC (solo deployment tra VPC): compute.networkAttachments.list (o roles/compute.networkAdmin) per gestire le connessioni Private Service Connect.
Gestione di GKE: roles/container.clusterAdmin per eseguire il deployment di risorse personalizzate (GCPBackend, GCPEgressPolicy).

Configura l'attendibilità per l'ispezione TLS

Se la policy di Secure Web Proxy utilizza l'ispezione TLS per ispezionare il traffico in uscita criptato, il proxy genera certificati firmati dalla sua autorità di certificazione (CA) privata per impersonare le destinazioni esterne.

L'applicazione del workload deve considerare attendibile il certificato CA privato presentato da Secure Web Proxy. Poiché GKE non inserisce questo certificato automaticamente, devi installare il certificato CA SWP (trust anchor) nell'archivio di attendibilità del container.

Per aggiungere il certificato CA all'immagine container, includi le seguenti righe nel Dockerfile:

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

Definisci l'endpoint del gateway

Il primo passaggio per configurare il routing in uscita ambientale consiste nel creare un endpoint gateway, che definisce l'endpoint Secure Web Proxy all'interno del tuo cluster GKE e informa Ambient Networking della posizione del proxy.

Per specificare l'URI del secure web proxy o del collegamento di servizio Private Service Connect (PSC), crea una risorsa personalizzata GCPBackend nel tuo cluster GKE:

Stesso VPC

Salva il seguente manifest come 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
```
Sostituisci quanto segue:
- ambient-test: lo spazio dei nomi registrato in Ambient Networking.
- PROJECT_ID: il tuo ID progetto Google Cloud .
- REGION: la regione in cui è stato eseguito il deployment di Secure Web Proxy.
- SWP_NAME: il nome del tuo Secure Web Proxy.
Applica la risorsa GCPBackend:
```
kubectl apply -f swp-backend.yaml
```

Tra VPC

Salva il seguente manifest come 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
```
Sostituisci quanto segue:
- ambient-test: lo spazio dei nomi registrato in Ambient Networking.
- PROJECT_ID: il tuo ID progetto Google Cloud .
- REGION: la regione in cui è stato eseguito il deployment del collegamento al servizio PSC.
- ATTACHMENT_NAME: il nome del collegamento al servizio PSC, se Secure Web Proxy si trova in una rete VPC diversa.
Applica la risorsa GCPBackend:
```
kubectl apply -f swp-backend.yaml
```

Configura il reindirizzamento del traffico in uscita

Crea una risorsa personalizzata GCPEgressPolicy per instradare il traffico in uscita dallo spazio dei nomi al gateway di Secure Web Proxy. In questo modo viene fornito l'invio di segnali necessario affinché il proxy del nodo ambient stabilisca un tunnel HTTP CONNECT verso Secure Web Proxy, necessario per il routing in uscita.

Salva il seguente manifest come 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
```
Sostituisci quanto segue:
- ambient-test: lo spazio dei nomi registrato in Ambient Networking.
- CLUSTER_CONTROL_PLANE_CIDR: l'intervallo CIDR per le comunicazioni interne che devono bypassare Secure Web Proxy (ad esempio l'intervallo di indirizzi del control plane GKE o le subnet VPC interne).
Applica la risorsa GCPEgressPolicy:
```
kubectl apply -f swp-egress-policy.yaml
```
Dopo l'applicazione della policy, il traffico in uscita dai workload nello spazio dei nomi viene reindirizzato a Secure Web Proxy.

Risoluzione dei problemi

Utilizza le seguenti indicazioni per diagnosticare e risolvere i problemi relativi al routing del traffico in uscita ambient:

Il traffico non raggiunge Secure Web Proxy:
- Per i deployment nella stessa VPC, verifica che la risorsa GCPBackend punti all'URI del gateway Secure Web Proxy corretto.
- Per i deployment tra VPC:
- Verifica che la risorsa GCPBackend punti all'URI del collegamento al servizio PSC corretto.
- Verifica che l'endpoint PSC sia stabilito e accettato nel VPC producer.
- Verifica che excludeCIDRRanges in GCPEgressPolicy non corrisponda inavvertitamente al traffico di destinazione.
Errori di connessione mTLS:
- Verifica che Secure Web Proxy sia configurato per accettare connessioni dal proxy del nodo.
Errori del certificato di ispezione TLS:
- Se le richieste client non vanno a buon fine con errori di convalida del certificato (ad esempio x509: certificate signed by unknown authority), verifica che il certificato CA di Secure Web Proxy sia installato correttamente nell'archivio dei certificati di sistema del container del workload.