Proteggere un gateway

Autopilot Standard

Questa pagina spiega come proteggere un gateway utilizzando varie funzionalità di sicurezza:

• Policy SSL per garantire che il gateway utilizzi i protocolli e gli algoritmi sicuri richiesti

• Certificati per proteggere il traffico da client a gateway e da gateway a backend con TLS

• Criteri 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 a un servizio

Per scoprire di più sulla sicurezza del gateway, consulta Sicurezza del gateway.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Requisiti del controller GKE Gateway

• L'API Gateway è supportata solo sui cluster VPC nativi.
• Se utilizzi GatewayClass regionali o tra regioni, devi attivare una subnet solo proxy.
• Il cluster deve avere il componente aggiuntivo HttpLoadBalancing abilitato.
• Se utilizzi Istio, devi eseguire l'upgrade 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 al service account GKE per il progetto di servizio.

• Assicurati di avere un cluster Autopilot o Standard esistente. Se ne hai bisogno, crea un cluster Autopilot.

Limitazioni e restrizioni

Oltre alle limitazioni del controller GKE Gateway, si applicano le seguenti limitazioni specifiche per la sicurezza del gateway:

• Le configurazioni TLS che utilizzano un certificato SSL o Certificate Manager sui gateway non sono supportate con GKE versione 1.28.4-gke.1083000. Utilizza un secret Kubernetes come soluzione alternativa per questa versione di GKE.

• Non puoi utilizzare l'annotazione networking.gke.io/certmap con un tls.certificateRefs nella stessa risorsa Gateway. Se fai riferimento a un CertificateMap in un gateway, GKE lo considererà un errore.

• Certificate Manager supporta sia i certificati autogestiti che quelli gestiti da Google. I certificati gestiti da Google sono compatibili con i gateway regionali e globali.

• Quando utilizzi certificati SSL gestiti da Google, devi creare i certificati SSL al di fuori di GKE prima di collegarli al gateway.

• Non puoi utilizzare lo stesso servizio come backend per un gateway regionale e uno globale se fai riferimento a una policy di sicurezza del backend Google Cloud Armor nella tua GCPBackendPolicy. Per questo caso d'uso, devi creare due servizi e norme separati.

• Il controller Gateway non supporta la risorsa ManagedCertificate.

• Il controller gateway non supporta l'annotazione networking.gke.io/managed-certificates.

• Se configuri Cloud CDN con GKE Gateway, non puoi abilitare sia IAP che Cloud CDN con lo stesso Gateway, incluse le singole route con Cloud CDN. Se devi attivare Cloud CDN per una route che utilizza una risorsa GCPHTTPFilter, devi prima rimuovere qualsiasi GCPBackendPolicy esistente che configuri IAP per il gateway.

• Quota TrustConfig. Per informazioni sulla dimensione totale di tutte le risorse TrustConfig in ogni posizione, consulta Quote e limiti delle risorse.

• Allineamento della posizione. La risorsa TrustConfig a cui viene fatto riferimento deve esistere nella stessa posizione (globale o regione specifica) del gateway che utilizza il servizio.

• Vincolo dello spazio dei nomi. La risorsa BackendTLSPolicy e la relativa risorsa di destinazione devono trovarsi nello stesso spazio dei nomi.

Per un elenco dei campi e delle funzionalità dell'API Gateway supportati delle risorse GatewayClass disponibili su GKE, consulta Funzionalità di GatewayClass.

Proteggere un gateway utilizzando un secret Kubernetes

In questo esempio, configuri un gateway utilizzando un secret Kubernetes.

Archivia un certificato in un secret Kubernetes

Puoi utilizzare un certificato emesso e convalidato dalla tua autorità di certificazione (CA) o creare un certificato autofirmato. I passaggi seguenti utilizzano un certificato autofirmato.

1. Crea una chiave privata:

   openssl genrsa -out PRIVATE_KEY_FILE 2048
   

   Sostituisci PRIVATE_KEY_FILE con il nome del file della chiave privata, ad esempio private-key.pem. Per saperne di più, consulta Selezionare o creare una chiave privata.

2. Crea un file di configurazione Open SSL:

   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 esempio config-file.cnf.

3. 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 esempio cert.pem. Per ulteriori informazioni, vedi Creare una richiesta CSR.

4. Firma la 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 esempio cert-file.pem. Per ulteriori informazioni, consulta Firma della CSR.

5. Crea un secret TLS di Kubernetes utilizzando la chiave e il file del 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 tuo gateway.

Crea un gateway e una HTTPRoute

1. Salva il seguente manifest come external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate
         certificateRefs: # Directly reference the Kubernetes Secret containing the TLS certificate and private key.
         - name: store-example-com # The name of the TLS secret.
   

   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 e port: 443: obbligatori per l'attivazione di TLS.
   • tls: fa riferimento al secret Kubernetes creato nel passaggio precedente.

2. Applica il manifest al cluster:

   kubectl apply -f external-gateway.yaml
   

3. Salva il seguente manifest come store-external-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http # Link this route to the 'external-http' Gateway.
     hostnames:
     - "store.example.com" # Match traffic for this hostname.
     rules:
     - backendRefs: # Define where to forward the traffic.
       - name: store-v1
         port: 8080
   

   Questo manifest descrive una risorsa HTTPRoute che corrisponde al traffico verso store.example.com e lo invia al servizio store-v1.

4. Applica il manifest al cluster:

   kubectl apply -f store-external-route.yaml
   

Verifica il gateway

Verifica che il gateway funzioni inviando una richiesta su internet.

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

2. 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 sul computer 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, necessario 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
   # This block shows the certificate details presented by the Gateway.
   # The value of the 'common name' field matches the requested hostname.
   * 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.

Proteggere un gateway utilizzando un certificato SSL

In questo esempio, configuri un gateway con un certificato SSL gestito da Google.

Nota: la configurazione di un certificato SSL e dell'annotazione networking.gke.io/certmap sullo stesso gateway non è una configurazione valida e il controller la tratterà come un errore.

Crea un certificato SSL

1. Crea una risorsa globale SslCertificate gestita da Google:

   gcloud compute ssl-certificates create store-example-com \
       --domains=store.example.com \
       --global
   

Crea un gateway e una HTTPRoute

1. Salva il seguente manifest come external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate # Terminate TLS using your SSL certificate.
         options:
           networking.gke.io/pre-shared-certs: store-example-com # Specify the Google Cloud SSL certificate resource name.
   

   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 e port:443: obbligatori per l'attivazione di TLS.
   • tls.mode:Terminate: termina TLS utilizzando il certificato SSL.

2. Applica il manifest al cluster:

   kubectl apply -f external-gateway.yaml
   

3. Salva il seguente manifest HTTPRoute come store-external-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
   

4. Esegui il deployment di HTTPRoute nel tuo cluster:

   kubectl apply -f store-external-route.yaml
   

   Il deployment del gateway potrebbe richiedere diversi minuti.

Verifica il gateway

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

2. Aggiorna un record A o AAAA per indirizzare il tuo 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.

   Una volta aggiornati i record DNS, possono essere necessari fino a 10 minuti prima che il bilanciatore del carico inizi a utilizzare il certificato gestito da Google.

3. Verifica che il gateway funzioni inviando una richiesta su 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. TLS viene terminato correttamente al gateway e l'applicazione risponde al client in modo sicuro.

Proteggere un gateway utilizzando Certificate Manager

In questo esempio, configuri un gateway utilizzando Certificate Manager.

Nota: la configurazione di un certificato SSL e dell'annotazione networking.gke.io/certmap sullo stesso gateway non è una configurazione valida e il controller la tratterà come un errore.

Crea un Certificate

Global Gateway

Per creare un gateway globale, fai riferimento a una risorsa mappa di certificati che contiene uno o più certificati. Devi creare almeno un certificato e aggiungerlo come voce alla mappa dei certificati.

1. Per creare un certificato, devi prima creare un file della chiave privata e del certificato.

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

3. Crea un CertificateMap:

   gcloud certificate-manager maps create store-example-com-map
   

4. Crea un CertificateMapEntry che assegni il certificato a CertificateMap:

   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 regionale, crei un Certificate che verrà specificato direttamente durante la creazione del gateway. A differenza di un gateway globale, non devi creare un CertificateMap a cui vengono assegnati i certificati.

1. Crea un file di chiave privata e certificato.

2. 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 esempio store-example-com-cert.
• CERTIFICATE_FILE: il nome del file del certificato, ad esempio cert.pem.
• PRIVATE_KEY_FILE: il nome del file della chiave privata, ad esempio private-key.pem. Per saperne di più, consulta Selezionare o creare una chiave privata.
• REGION: il nome della regione in cui stai configurando il gateway, ad esempio us-central1.

Nota: se utilizzi un gateway cross-region, sostituisci il flag --location con un flag --scope=all-regions. Se non utilizzi --scope=all-regions, il certificato non verrà trovato durante la creazione del gateway. Ad esempio 'Certificate' was not found.

Crea un gateway e una HTTPRoute

Global Gateway

Per creare un gateway globale, completa i seguenti passaggi:

1. Salva il seguente manifest come cert-map-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   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
     # No TLS section is included here because TLS is handled by the certmap annotation.
   

   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 e port: 443: obbligatori per l'attivazione di TLS.

   Non è presente una sezione TLS perché TLS è configurato con Certificate Manager utilizzando l'annotazione networking.gke.io/certmap.

2. Applica il manifest al cluster:

   kubectl apply -f cert-map-gateway.yaml
   

   Il deployment del gateway potrebbe richiedere diversi minuti.

3. Per creare un HTTPRoute, salva il seguente manifest come cert-map-http-route.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   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
   

4. Applica il manifest al cluster:

   kubectl apply -f cert-map-http-route.yaml
   

Gateway regionale

Quando crei un gateway regionale, puoi specificare i certificati gestiti da Certificate Manager e i certificati gestiti da Compute Engine.

1. Per creare un gateway esterno regionale, salva il seguente manifest come external-gateway.yaml:

      kind: Gateway
      apiVersion: gateway.networking.k8s.io/v1
      metadata:
        name: gateway
        namespace: corp
      spec:
        gatewayClassName: gke-l7-regional-external-managed
        listeners:
        - name: gateway-pre-shared-certmap
          protocol: HTTPS
          port: 443
          tls:
            mode: Terminate # TLS is terminated at the Gateway.
            options: # Specifies a comma-separated list of Certificate Manager certificates to use for TLS termination.
              networking.gke.io/cert-manager-certs: store-example-com-cert1, store-example-com-cert2 # These certificates are directly managed by Certificate Manager.
          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 e port: 443: obbligatori per l'attivazione di TLS.
   • options:
     • networking.gke.io/cert-manager-certs : certificati gestiti da Certificate Manager.

   Per creare un gateway interno regionale, nell'esempio precedente, modifica il valore di gatewayClassName in gke-l7-rilb. Viene eseguito il deployment di un bilanciatore del carico delle applicazioni interno.

2. Applica il manifest al cluster:

   kubectl apply -f external-gateway.yaml
   

3. Per creare un HTTPRoute, salva il seguente manifest come store-external-route.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   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 un HTTPRoute che corrisponde al traffico per store.example.com e lo inoltra al servizio store-v1.

4. Applica il manifest al cluster:

   kubectl apply -f store-external-route.yaml
   

Verifica il gateway

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

2. Aggiorna un record A o AAAA per indirizzare il tuo 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.

   Una volta aggiornati i record DNS, possono essere necessari fino a 10 minuti prima che il bilanciatore del carico inizi a utilizzare il certificato gestito da Google.

3. 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 sul computer 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. TLS viene terminato correttamente al gateway e l'applicazione risponde al client in modo sicuro.

Configura TLS di backend per un gateway

TLS backend consente al bilanciatore del carico GKE Gateway di verificare l'identità dei backend a cui si connette. TLS del backend aggiunge un passaggio di verifica esplicito durante l'handshake TLS tra il gateway e il pod backend. Il gateway funge da client TLS, convalidando il certificato del server di backend in base a un insieme di autorità di certificazione (CA) attendibili che configuri. Questa verifica viene eseguita quando viene stabilita una nuova connessione, garantendo che il gateway comunichi solo con i backend attendibili e migliorando la sicurezza complessiva.

Nota: assicurati che i pod dell'applicazione eseguano un server HTTPS sulla porta di destinazione del servizio o di InferencePool.

Puoi configurare TLS autenticato del backend utilizzando una risorsa BackendTLSPolicy associata a un servizio, un InferencePool, un ServiceImport o un GCPInferencePoolImport. BackendTLSPolicy deve risiedere nello stesso spazio dei nomi della risorsa di destinazione.

TLS di backend è supportato per le seguenti GatewayClass:

• gke-l7-global-external-managed e gke-l7-global-external-managed-mc (supporta solo i backend Service e ServiceImport)
• gke-l7-regional-external-managed e gke-l7-regional-external-managed-mc
• gke-l7-rilb e gke-l7-rilb-mc
• gke-l7-cross-regional-internal-managed-mc

Utilizza una ConfigMap Kubernetes (standard)

Nota: consigliamo questo metodo per configurare TLS di backend perché utilizza oggetti integrati Kubernetes standard ed è completamente conforme all'API Gateway.

In questo metodo, fornisci il certificato CA direttamente in un ConfigMap di Kubernetes.

1. Crea una risorsa ConfigMap contenente i certificati CA con codifica PEM. Per maggiori informazioni, consulta i requisiti dei certificati. Ogni ConfigMap deve contenere un solo certificato CA. Devi creare questo ConfigMap nello stesso spazio dei nomi della risorsa BackendTLSPolicy. BackendTLSPolicy non supporta i riferimenti tra spazi dei nomi alle risorse ConfigMap.

   Nota: una singola BackendTLSPolicy supporta il riferimento a un massimo di otto risorse ConfigMap nel campo caCertificateRefs.

   I dati del certificato devono essere inseriti sotto la chiave ca.crt:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: my-backend-ca
   data:
     ca.crt: |
       -----BEGIN CERTIFICATE-----
       PEM_DATA
       -----END CERTIFICATE-----
   

   Sostituisci PEM_DATA con i contenuti con codifica Base64 e formato PEM del certificato CA.

2. Definisci come target un servizio, un InferencePool, un ServiceImport o un GCPInferencePoolImport con un BackendTLSPolicy che fa riferimento a ConfigMap:

   Servizio

   Il seguente manifest mostra una BackendTLSPolicy che ha come target un servizio:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy
   spec:
     targetRefs:
     - group: "" # empty group means Core API.
       kind: Service
       name: my-service-name
     validation:
       hostname: "backend.example.com"
       caCertificateRefs:
       - group: "" # empty group means Core API.
         kind: ConfigMap
         name: my-backend-ca
   

   InferencePool

   Il seguente manifest mostra una BackendTLSPolicy che ha come target un InferencePool:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy-inferencepool
   spec:
     targetRefs:
     - group: "inference.networking.k8s.io" # For InferencePool
       kind: InferencePool
       name: my-inference-pool
     validation:
       hostname: "backend.example.com"
       caCertificateRefs:
       - group: "" # empty group means Core API.
         kind: ConfigMap
         name: my-backend-ca
   

   ServiceImport

   Il seguente manifest mostra una risorsa BackendTLSPolicy che ha come target un ServiceImport:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy-serviceimport
   spec:
     targetRefs:
     - group: "net.gke.io" # For ServiceImport
       kind: ServiceImport
       name: my-service-import
     validation:
       hostname: "backend.example.com"
       caCertificateRefs:
       - group: "" # empty group means Core API.
         kind: ConfigMap
         name: my-backend-ca
   

   GCPInferencePoolImport

   Il seguente manifest mostra una BackendTLSPolicy che ha come target un GCPInferencePoolImport:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy-gcpinferencepoolimport
   spec:
     targetRefs:
     - group: "networking.gke.io" # For GCPInferencePoolImport
       kind: GCPInferencePoolImport
       name: my-gcp-inference-pool-import
     validation:
       hostname: "backend.example.com"
       caCertificateRefs:
       - group: "" # empty group means Core API.
         kind: ConfigMap
         name: my-backend-ca
   

Utilizzare un TrustConfig autogestito (avanzato)

Nota: utilizza questo metodo se la tua configurazione richiede funzionalità avanzate come l'inserimento nella lista consentita dei certificati o se supera le limitazioni standard dell'API Gateway, come il numero massimo di certificati intermedi o di ancoraggio attendibile supportati.

Questo metodo consente di fare riferimento a una risorsa TrustConfig che gestisci in modo indipendente in Google Cloud Certificate Manager.

1. Crea una risorsa TrustConfig in Certificate Manager. TrustConfig deve essere creato nello stesso progetto e nella stessa località del gateway.

   • Per i gateway globali o multi-cluster (inclusi quelli multi-cluster regionali) e i gateway cross-region, utilizza la località global.
   • Per i gateway regionali a singolo cluster, utilizza la stessa regione del gateway.
   • Se il tuo servizio viene utilizzato da più gateway in posizioni diverse, devi creare una risorsa TrustConfig con lo stesso nome in ciascuna di queste posizioni.

2. Seleziona come target un servizio con una risorsa BackendTLSPolicy che fa riferimento alla risorsa TrustConfig esterna tramite il campo options:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy
   spec:
     targetRefs:
     - group: "" # empty group means Core API.
       kind: Service
       name: my-service-name
     validation:
       wellKnownCACertificates: "System"
       hostname: "backend.example.com"
       options:
         networking.gke.io/backend-trust-config: "my-trust-config-name"
   

   Nota: non puoi utilizzare le impostazioni wellKnownCACertificates: "System" e caCertificateRefs nello stesso oggetto. In questo modo, il criterio non è valido.

Riferimento ai campi BackendTLSPolicy

La tabella seguente descrive i campi chiave di una risorsa BackendTLSPolicy:

Campo	Descrizione
targetRefs	Le risorse di backend a cui si applica questa policy. Supporta Service (group: ""), InferencePool (group: "inference.networking.k8s.io"), ServiceImport (group: "net.gke.io") o GCPInferencePoolImport (group: "networking.gke.io"). Nota:per gke-l7-global-external-managed e gke-l7-global-external-managed-mc GatewayClass, sono supportati solo i backend Service e ServiceImport.
validation.hostname	Il nome host (SNI) utilizzato dal gateway durante l'handshake TLS con i pod di backend.
validation.subjectAltNames	Facoltativo. Definisce uno o più nomi alternativi del soggetto (SAN) da convalidare rispetto al certificato del backend. Supporta Hostname e URI (ad esempio gli ID SPIFFE).
validation.caCertificateRefs	Metodo standard. Fa riferimento a un elenco di risorse ConfigMap (fino a otto) nello stesso spazio dei nomi. Ogni ConfigMap deve contenere un singolo certificato CA con codifica PEM nella chiave ca.crt. I riferimenti tra spazi dei nomi non sono supportati.
validation.wellKnownCACertificates	Metodo avanzato. Imposta il valore su System quando utilizzi un TrustConfig autogestito.
options	Una mappa per opzioni specifiche di GKE. Utilizza l'impostazione networking.gke.io/backend-trust-config per fare riferimento a una risorsa TrustConfig esterna.

Verifica la configurazione TLS del backend

Dopo aver applicato BackendTLSPolicy, verifica che il controller Gateway abbia accettato la configurazione controllando lo stato della policy:

kubectl describe backendtlspolicy POLICY_NAME

Sostituisci POLICY_NAME con il nome della tua policy.

Un criterio viene applicato correttamente se contiene le condizioni Accepted e ResolvedRefs con Status: "True" nella sezione Status.Ancestors:

Status:
  Ancestors:
  - Ancestor Ref:
      Group: gateway.networking.k8s.io
      Kind: Gateway
      Name: my-gateway-name
      Namespace: default
    Conditions:
    - Last Transition Time: "2026-02-17T15:19:26Z"
      Message: ""
      Reason: Accepted
      Status: "True"
      Type: Accepted
    - Last Transition Time: "2026-02-17T15:19:26Z"
      Message: ""
      Reason: ResolvedRefs
      Status: "True"
      Type: ResolvedRefs
    Controller Name: networking.gke.io/gateway

Se Status è False per una qualsiasi di queste condizioni, significa che la norma non è stata applicata. Per maggiori dettagli, controlla i campi Reason e Message. Gli errori più comuni includono il riferimento a un ConfigMap in caCertificateRefs che non esiste o a cui manca la chiave ca.crt.

Questo stato conferma che il gateway ha convalidato correttamente la policy e ha applicato le impostazioni TLS ai backend del servizio o del pool di inferenza di destinazione. La risorsa BackendTLSPolicy deve risiedere nello stesso spazio dei nomi della risorsa di destinazione.

Proteggere il bilanciatore del carico dal traffico dell'applicazione utilizzando 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, HTTP2 e kubernetes.io/h2c.

Il seguente manifest descrive un servizio che specifica che il bilanciatore del carico deve utilizzare il traffico HTTPS per comunicare 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à assicurarti che il certificato utilizzato nei pod di backend sia valido.

Nota: il valore networking.gke.io/app-protocol precedentemente supportato è stato ritirato. Questa annotazione non è supportata dal controller GKE Gateway.

Proteggere il traffico dal client al bilanciatore del carico utilizzando i criteri SSL

Quando le tue applicazioni vengono esposte tramite un gateway esterno che utilizza HTTPS, è importante utilizzare i protocolli più recenti o specificare la versione minima di SSL o TLS. Puoi proteggere il traffico dal client al bilanciatore del carico utilizzando le policy SSL.

Per saperne di più 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.

Proteggere i backend utilizzando Google Cloud Armor

I criteri di sicurezza di Google Cloud Armor ti aiutano a proteggere le tue applicazioni con bilanciamento del carico dagli attacchi basati sul web. Dopo aver configurato una policy di sicurezza Google Cloud Armor, puoi farvi riferimento in un GCPBackendPolicy applicato ai tuoi servizi Kubernetes.

Per configurare le policy di Google Cloud Armor con il gateway, consulta Configura la policy di sicurezza di Google Cloud Armor per proteggere i servizi di backend.

Autenticare le richieste ai backend utilizzando Identity-Aware Proxy

Identity-Aware Proxy ti aiuta a 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.

Nota: IAP non è compatibile con Cloud CDN. Se la tua applicazione richiede memorizzazione in una cache perimetrale utilizzando la risorsa GCPHTTPFilter, assicurati che IAP non sia abilitato per lo stesso gateway o le relative route. Per saperne di più sulla configurazione della memorizzazione nella cache, consulta Configurare Cloud CDN per Gateway.

Passaggi successivi

• Scopri di più sulla sicurezza del gateway.
• Scopri come configurare le risorse del gateway utilizzando i criteri.
• Scopri come eseguire il deployment dei gateway.
• Scopri di più sull'API Gateway