In questa pagina viene spiegato come proteggere un gateway utilizzando varie funzionalità di sicurezza:
Criteri SSL per garantire che il gateway utilizzi i protocolli e gli algoritmi di sicurezza richiesti
Certificati per proteggere il traffico da client a gateway e da gateway a backend con TLS
Criterio di sicurezza di Google Cloud Armor per proteggere i servizi dagli attacchi DDoS
- Identity-Aware Proxy (IAP) per fornire un livello di autenticazione e autorizzazione prima di consentire l'accesso
Per scoprire di più sulla sicurezza del gateway, consulta Sicurezza del gateway.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update
.
Requisiti del controller gateway GKE
- Per Standard, GKE versione 1.24 o successive.
- Per Autopilot, GKE versione 1.26 o successive.
- Google Cloud CLI versione 407.0.0 o successive.
- L'API Gateway è supportata solo sui cluster nativi VPC.
- Se utilizzi GatewayClass interni, devi abilitare una subnet solo proxy.
- Nel cluster deve essere abilitato il componente aggiuntivo
HttpLoadBalancing
. - Se utilizzi Istio, devi eseguire l'upgrade di Istio a una delle seguenti
versioni:
- 1.15.2 o versioni successive
- 1.14.5 o versioni successive
- 1.13.9 o versioni successive.
- Se utilizzi un VPC condiviso, nel progetto host devi assegnare il ruolo
Compute Network User
all'account di servizio GKE per il progetto di servizio.
Restrizioni e limitazioni
Oltre alle limitazioni e limitazioni del controller GKE Gateway, per la sicurezza del gateway si applicano in particolare le seguenti limitazioni:
- Le configurazioni TLS che utilizzano un certificato SSL o un Gestore certificati sui gateway non sono supportate con GKE versione 1.28.4-gke.1083000. Usa un secret Kubernetes come soluzione alternativa per questa versione GKE.
- Non puoi utilizzare l'annotazione
networking.gke.io/certmap
con untls.certificateRefs
sulla stessa risorsa gateway. Se fai riferimento a unCertificateMap
in un gateway, GKE lo considererà un errore.
- Certificate Manager supporta sia i certificati autogestiti sia quelli gestiti da Google. I certificati gestiti da Google sono compatibili con i gateway regionali (disponibili in Anteprima) e i gateway globali.
Quando utilizzi i certificati SSL gestiti da Google, devi crearli all'esterno di GKE prima di collegarli al tuo gateway.
I certificati SSL gestiti da Google non sono compatibili con i gateway regionali. Per ulteriori informazioni sui metodi di terminazione TLS per ogni GatewayClass, consulta Supporto per TLS di GatewayClass.
Non puoi utilizzare lo stesso servizio di un backend per un gateway regionale e globale se fai riferimento a un criterio di sicurezza del backend Google Cloud Armor in
GCPBackendPolicy
. Devi creare due servizi e criteri separati per questo caso d'uso.Il controller gateway non supporta la risorsa
ManagedCertificate
.Il controller gateway non supporta l'annotazione
networking.gke.io/managed-certificates
.Il campo
appProtocol
nella configurazione del servizio accetta solo lettere maiuscole per il valore del protocollo (HTTP
,HTTPS
oHTTP2
). L'utilizzo di lettere minuscole comporta l'utilizzo del protocollo HTTP con i backend.
Per un elenco dei campi dell'API Gateway supportati e delle funzionalità delle risorse GatewayClass disponibili su GKE, consulta Funzionalità di GatewayClass.
Proteggi un gateway con un secret di Kubernetes
In questo esempio, configuri un gateway utilizzando un secret di Kubernetes.
Archivia un certificato in un secret Kubernetes
Puoi utilizzare un certificato emesso e convalidato dall'autorità di certificazione (CA) o creare un certificato autofirmato. Nei passaggi seguenti viene utilizzato un certificato autofirmato.
Crea una chiave privata:
openssl genrsa -out PRIVATE_KEY_FILE 2048
Sostituisci
PRIVATE_KEY_FILE
con il nome del file della chiave privata, ad esempioprivate-key.pem
. Per maggiori informazioni, consulta Selezionare o creare una chiave privata.Crea un file di configurazione SSL aperto:
cat <<EOF >CONFIG_FILE [req] default_bits = 2048 req_extensions = extension_requirements distinguished_name = dn_requirements prompt = no [extension_requirements] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @sans_list [dn_requirements] 0.organizationName = example commonName = store.example.com [sans_list] DNS.1 = store.example.com EOF
Sostituisci
CONFIG_FILE
con il nome del nuovo file di configurazione, ad esempioconfig-file.cnf
.Crea un file di richiesta di firma del certificato (CSR):
openssl req -new -key PRIVATE_KEY_FILE \ -out CSR_FILE \ -config CONFIG_FILE
Sostituisci
CSR_FILE
con il nome del nuovo file CSR, ad esempiocert.pem
. Per ulteriori informazioni, consulta Creare una richiesta di firma del certificato.Firma la richiesta di firma del certificato (CSR):
openssl x509 -req \ -signkey PRIVATE_KEY_FILE \ -in CSR_FILE \ -out CERTIFICATE_FILE \ -extfile CONFIG_FILE \ -extensions extension_requirements \ -days 30
Sostituisci
CERTIFICATE_FILE
con il percorso e il nome del file generato dal comando, ad esempiocert-file.pem
. Per ulteriori informazioni, consulta Firmare la richiesta di firma del certificato (CSR).Crea un secret TLS di Kubernetes utilizzando la chiave e il file di certificato che hai creato:
kubectl create secret tls store-example-com \ --cert=CERTIFICATE_FILE \ --key=PRIVATE_KEY_FILE
GKE salva il certificato e la chiave come risorsa Kubernetes che puoi collegare al Gateway.
Crea un gateway e un protocollo HTTPRoute
Salva il seguente manifest come
external-gateway.yaml
:kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: external-http spec: gatewayClassName: gke-l7-global-external-managed listeners: - name: https protocol: HTTPS port: 443 tls: mode: Terminate certificateRefs: - name: store-example-com
Questo manifest descrive un gateway con le seguenti proprietà:
gatewayClassName: gke-l7-global-external-managed
: esegue il deployment di un bilanciatore del carico delle applicazioni esterno globale.protocol: HTTPS
eport: 443
: obbligatori per attivare TLS.tls
: fa riferimento al secret di Kubernetes creato nel passaggio precedente.
Applica il manifest al cluster:
kubectl apply -f external-gateway.yaml
Salva il seguente manifest come
store-external-route.yaml
:kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: store-external labels: gateway: external-http spec: parentRefs: - name: external-http hostnames: - "store.example.com" rules: - backendRefs: - name: store-v1 port: 8080
Questo manifest descrive una rete HTTPRoute che corrisponde al traffico verso
store.example.com
e lo invia al serviziostore-v1
.Applica il manifest al cluster:
kubectl apply -f store-external-route.yaml
Verifica il gateway
Verifica che il gateway funzioni inviando una richiesta tramite internet.
Ottieni l'indirizzo IP del gateway:
kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
L'output è simile al seguente:
203.0.113.12
Questo output è un indirizzo IP pubblico, il che significa che qualsiasi client con accesso a internet può connettersi a questo indirizzo.
Accedi al dominio del gateway utilizzando
curl
:curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v
Sostituisci quanto segue:
GATEWAY_IP_ADDRESS
: l'indirizzo IP del bilanciatore del carico del gateway.CERTIFICATE_FILE
: il file del certificato che hai generato. Devi salvare questo file sulla macchina che utilizzi per connetterti al gateway. Il certificato è necessario per autenticare il gateway perché utilizza un certificato autofirmato.
L'opzione
--resolve
risolve il nome di dominio nell'indirizzo IP del gateway, che è obbligatorio perché il DNS non è configurato per questo dominio.L'output è simile al seguente:
... * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: O=example; CN=store.example.com * start date: Apr 19 15:54:50 2021 GMT * expire date: Apr 19 15:54:50 2022 GMT * common name: store.example.com (matched) * issuer: O=example; CN=store.example.com * SSL certificate verify ok. ... { "cluster_name": "gw", "host_header": "store.example.com", "metadata": "store-v1", "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal", "pod_name": "store-v1-84b47c7f58-tj5mn", "pod_name_emoji": "😍", "project_id": "agmsb-k8s", "timestamp": "2021-04-19T16:30:08" # Several lines of output omitted here. }
Questo output include un handshake TLS riuscito seguito da una risposta dall'applicazione. La connessione TLS viene terminata al gateway e l'applicazione risponde al client in modo sicuro.
Proteggi un gateway utilizzando un certificato SSL
In questo esempio, configuri un gateway con un certificato SSL gestito da Google.
Crea un certificato SSL
Crea una risorsa
SslCertificate
globale gestita da Google:gcloud compute ssl-certificates create store-example-com \ --domains=store.example.com \ --global
Crea un gateway e un protocollo HTTPRoute
Salva il seguente manifest come
external-gateway.yaml
:kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: external-http spec: gatewayClassName: gke-l7-global-external-managed listeners: - name: https protocol: HTTPS port: 443 tls: mode: Terminate options: networking.gke.io/pre-shared-certs: store-example-com
Questo manifest descrive un gateway con le seguenti proprietà:
gatewayClassName: gke-l7-global-external-managed
: esegue il deployment di un bilanciatore del carico delle applicazioni esterno globale.protocol:HTTPS
eport:443
: obbligatori per attivare TLS.tls.mode:Terminate
: termina TLS utilizzando il certificato SSL.
Applica il manifest al cluster:
kubectl apply -f external-gateway.yaml
Salva il seguente manifest HTTPRoute come
store-external-route.yaml
:kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: store-external labels: gateway: external-http spec: parentRefs: - name: external-http hostnames: - "store.example.com" rules: - backendRefs: - name: store-v1 port: 8080
Esegui il deployment di HTTPRoute nel cluster:
kubectl apply -f store-external-route.yaml
Il deployment del gateway da parte di GKE potrebbe richiedere diversi minuti.
Verifica il gateway
Ottieni l'indirizzo IP del gateway:
kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
L'output è simile al seguente:
203.0.113.12
Questo output è un indirizzo IP pubblico, il che significa che qualsiasi client con accesso a internet può connettersi a questo indirizzo.
Aggiorna un record A o AAAA per indirizzare il dominio all'indirizzo IP del gateway.
Questo passaggio è necessario solo se stai configurando un certificato SSL gestito da Google. Se stai configurando un certificato autogestito, puoi saltare questo passaggio.
Dopo l'aggiornamento dei record DNS, potrebbero essere necessari fino a 10 minuti prima che il bilanciatore del carico inizi a utilizzare il certificato gestito da Google.
Verifica che il gateway funzioni inviando una richiesta tramite internet utilizzando
curl
:curl https://store.example.com -v
L'output è simile al seguente:
... * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: O=example; CN=store.example.com * start date: Apr 19 15:54:50 2021 GMT * expire date: Apr 19 15:54:50 2022 GMT * common name: store.example.com (matched) * issuer: O=example; CN=store.example.com * SSL certificate verify ok. ... { "cluster_name": "gw", "host_header": "store.example.com", "metadata": "store-v1", "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal", "pod_name": "store-v1-84b47c7f58-tj5mn", "pod_name_emoji": "😍", "project_id": "agmsb-k8s", "timestamp": "2021-04-19T16:30:08", "zone": "us-west1-a" }
Questo output include un handshake TLS riuscito e una risposta dall'applicazione. Il TLS viene terminato correttamente al gateway e l'applicazione risponde al client in modo sicuro.
Proteggi un gateway utilizzando Gestore certificati
In questo esempio, configuri un gateway utilizzando Gestore certificati.
Crea un Certificate
Gateway globale
Per creare un gateway globale, fai riferimento a una risorsa mappa dei certificati contenente uno o più certificati. Devi creare almeno un certificato e aggiungerlo come voce alla mappa di certificati.
Per creare un certificato, crea prima una chiave privata e un file di certificato.
Crea una risorsa
Certificate
caricando il certificato e la chiave autogestiti:gcloud certificate-manager certificates create store-example-com-cert \ --certificate-file="cert.pem" \ --private-key-file="PRIVATE_KEY_FILE"
Crea un
CertificateMap
:gcloud certificate-manager maps create store-example-com-map
Crea un
CertificateMapEntry
che assegna il certificato alCertificateMap
:gcloud certificate-manager maps entries create store-example-com-map-entry \ --map=store-example-com-map \ --hostname=store.example.com \ --certificates=store-example-com-cert
Gateway regionale
Per un gateway a livello di regione, puoi creare un Certificate
che verrà specificato direttamente durante la creazione del gateway. A differenza di un gateway globale, non è necessario creare un CertificateMap
a cui vengono assegnati i certificati.
Crea una chiave privata e un file di certificato.
Crea una risorsa
Certificate
caricando il file del certificato e la chiave:
gcloud certificate-manager certificates create "CERTIFICATE_NAME" \
--certificate-file="CERTIFICATE_FILE" \
--private-key-file="PRIVATE_KEY_FILE" \
--location="REGION"
Sostituisci quanto segue:
CERTIFICATE_NAME
: il nome del certificato, ad esempiostore-example-com-cert
.CERTIFICATE_FILE
: il nome del file del certificato, ad esempiocert.pem
.PRIVATE_KEY_FILE
: il nome del file della chiave privata, ad esempioprivate-key.pem
. Per maggiori informazioni, consulta Selezionare o creare una chiave privata.REGION
: il nome della regione in cui stai configurando il gateway, ad esempious-central1
.
Crea un gateway e un protocollo HTTPRoute
Gateway globale
Per creare un gateway globale, completa i seguenti passaggi:
Salva il seguente manifest come
cert-map-gateway.yaml
:kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: external-http annotations: networking.gke.io/certmap: store-example-com-map spec: gatewayClassName: gke-l7-global-external-managed listeners: - name: https protocol: HTTPS port: 443
Questo manifest descrive un gateway con le seguenti proprietà:
gatewayClassName: gke-l7-global-external-managed
: esegue il deployment di un bilanciatore del carico delle applicazioni esterno globale.protocol: HTTPS
eport: 443
: obbligatori per attivare TLS.
Non esiste una sezione TLS perché TLS è configurato con Gestore certificati utilizzando l'annotazione
networking.gke.io/certmap
.Applica il manifest al cluster:
kubectl apply -f cert-map-gateway.yaml
Il deployment del gateway da parte di GKE potrebbe richiedere diversi minuti.
Per creare una HTTPRoute, salva il manifest seguente come
cert-map-http-route.yaml
:apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: foo namespace: default spec: parentRefs: - name: external-http hostnames: - foo.example.com rules: - matches: - path: value: / backendRefs: - name: foo-v1 port: 8080
Applica il manifest al cluster:
kubectl apply -f cert-map-http-route.yaml
Gateway regionale
Quando crei un gateway a livello di regione, puoi specificare i certificati gestiti da Gestore certificati e quelli gestiti da Compute Engine.
Per creare un gateway esterno regionale, salva il manifest seguente come
external-gateway.yaml
:kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: gateway namespace: corp spec: gatewayClassName: gke-17-regional-external-managed listeners: - name: gateway-pre-shared-certmap protocol: HTTPS port: 443 tls: mode: Terminate options: networking.gke.io/cert-manager-certs: store-example-com-cert1, store-example-com-cert2 allowedRoutes: kinds: - kind: HTTPRoute namespaces: from: All
Questo manifest descrive un gateway con le seguenti proprietà:
gatewayClassName
:gke-l7-regional-external-managed
: esegue il deployment di un bilanciatore del carico delle applicazioni esterno regionale.protocol: HTTPS
eport: 443
: obbligatori per attivare TLS.options
:networking.gke.io/cert-manager-certs
: certificati gestiti da Gestore certificati.
Per creare un gateway interno a livello di regione, nell'esempio precedente, modifica il valore di
gatewayClassName
ingke-17-rilb
. Questa operazione esegue il deployment di un bilanciatore del carico delle applicazioni interno.Applica il manifest al cluster:
kubectl apply -f external-gateway.yaml
Per creare una HTTPRoute, salva il manifest seguente come
store-external-route.yaml
:apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: store-external labels: gateway: external-http spec: parentRefs: - name: external-http hostnames: - "store.example.com" rules: backendRefs: - name: store-v1 port: 8080
Questo manifest descrive una rete HTTPRoute che corrisponde al traffico per
store.example.com
e inoltra il traffico al serviziostore-v1
.Applica il manifest al cluster:
kubectl apply -f store-external-route.yaml
Verifica il gateway
Ottieni l'indirizzo IP del gateway:
kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
L'output è simile al seguente:
203.0.113.12
Questo output è un indirizzo IP pubblico, il che significa che qualsiasi client con accesso a internet può connettersi a questo indirizzo.
Aggiorna un record A o AAAA per indirizzare il dominio all'indirizzo IP del gateway.
Questo passaggio è necessario solo se stai configurando un certificato SSL gestito da Google. Se stai configurando un certificato autogestito, puoi saltare questo passaggio.
Dopo l'aggiornamento dei record DNS, potrebbero essere necessari fino a 10 minuti prima che il bilanciatore del carico inizi a utilizzare il certificato gestito da Google.
Accedi al dominio del gateway utilizzando
curl
:curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v
Sostituisci quanto segue:
GATEWAY_IP_ADDRESS
: l'indirizzo IP del bilanciatore del carico del gateway.CERTIFICATE_FILE
: il file del certificato che hai generato. Devi salvare questo file sulla macchina che utilizzi per connetterti al gateway. Il certificato è necessario per autenticare il gateway perché utilizza un certificato autofirmato.
L'output è simile al seguente:
... * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: O=example; CN=store.example.com * start date: Apr 19 15:54:50 2021 GMT * expire date: Apr 19 15:54:50 2022 GMT * common name: store.example.com (matched) * issuer: O=example; CN=store.example.com * SSL certificate verify ok. ... { "cluster_name": "gw", "host_header": "store.example.com", "metadata": "store-v1", "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal", "pod_name": "store-v1-84b47c7f58-tj5mn", "pod_name_emoji": "😍", "project_id": "agmsb-k8s", "timestamp": "2021-04-19T16:30:08", "zone": "us-west1-a" }
Questo output include un handshake TLS riuscito e una risposta dall'applicazione. Il TLS viene terminato correttamente al gateway e l'applicazione risponde al client in modo sicuro.
Proteggi il bilanciatore del carico per il traffico delle applicazioni tramite TLS
Puoi criptare il traffico dal bilanciatore del carico ai pod di backend utilizzando il campo ports[].appProtocol
. I campi supportati per appProtocol
sono: HTTP
,
HTTPS
e HTTP2
.
Il manifest seguente descrive un servizio che specifica che il bilanciatore del carico deve utilizzare il traffico HTTPS per la comunicazione con i pod di backend:
apiVersion: v1
kind: Service
metadata:
name: store-v2
spec:
selector:
app: store
version: v2
ports:
- port: 8080
targetPort: 8080
appProtocol: HTTPS
Il bilanciatore del carico non verifica il certificato utilizzato dai pod di backend. È tua responsabilità garantire che il certificato utilizzato nei pod di backend sia valido.
Proteggi il traffico dal client al bilanciatore del carico utilizzando i criteri SSL
Quando le applicazioni sono esposte tramite un gateway esterno che utilizza HTTPS, è importante utilizzare i protocolli più recenti o specificare la versione SSL o TLS minima. Puoi proteggere il client dal traffico del bilanciatore del carico utilizzando i criteri SSL.
Per ulteriori informazioni sui criteri SSL che possono essere collegati al tuo gateway e su come crearli, consulta Configurare i criteri SSL per proteggere il traffico dal client al bilanciatore del carico.
Proteggi i tuoi backend con Google Cloud Armor
I criteri di sicurezza di Google Cloud Armor ti aiutano a proteggere le applicazioni con bilanciamento del carico dagli attacchi basati sul web. Dopo aver configurato un criterio di sicurezza di Google Cloud Armor, puoi farvi riferimento in un GCPBackendPolicy
applicato ai tuoi servizi Kubernetes.
Per configurare i criteri di Google Cloud Armor con il gateway, consulta Configurare il criterio di sicurezza di Google Cloud Armor per proteggere i servizi di backend.
Autentica le richieste ai tuoi backend utilizzando Identity-Aware Proxy
Identity-Aware Proxy consente di proteggere i backend dal traffico indesiderato autenticando i client che inviano richieste alle tue applicazioni e applicando l'autorizzazione del traffico basata sui ruoli. Dopo aver abilitato Identity-Aware Proxy per GKE, puoi fare riferimento alle tue credenziali OAuth in un GCPBackendPolicy
applicato ai tuoi servizi Kubernetes.
Per configurare Identity-Aware Proxy con il gateway, vedi Configurare Identity-Aware Proxy.
Passaggi successivi
- Scopri di più sulla sicurezza del gateway.