Proteggi un gateway

Autopilot . . Standard

---

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 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 attività:

• Attiva l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine .
• Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi initialize con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  Nota: per gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti località predefinite, puoi evitare errori in gcloud CLI come i seguenti: One of [--zone, --region] must be supplied: Please specify location.

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 su Nativo VPC di cluster GKE.
• Se si utilizzano le classi gateway interne, è necessario abilitare un 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 opzioni versions:
  • 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, le seguenti limitazioni si applicano in modo specifico alla sicurezza del gateway:

• Configurazioni TLS che utilizzano un certificato SSL o Certificate Manager su I gateway non sono supportati 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 considera un errore.

• Gestore certificati supporta sia gli account autogestiti sia quelli gestiti da Google certificati. I certificati gestiti da Google sono compatibili con i gateway regionali (disponibili in Anteprima) e i gateway globali.

• Quando utilizzi certificati SSL gestiti da Google, devi creare il protocollo all'esterno di GKE prima di collegarli 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, vedi Supporto per TLS GatewayClass.

• Non puoi utilizzare lo stesso servizio di un backend per un'istanza Gateway se fai riferimento a un criterio di sicurezza del backend Google Cloud Armor nel tuo 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 Annotazione networking.gke.io/managed-certificates.

• Il campo appProtocol nella configurazione del servizio accetta solo lettere maiuscole lettere per il valore del protocollo (HTTP, HTTPS o HTTP2). Utilizzo Le lettere minuscole comportano l'utilizzo di HTTP come protocollo con i backend.

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

Proteggi un gateway con un secret di Kubernetes

In questo esempio, configuri un gateway utilizzando una Segreto di Kubernetes.

Archivia un certificato in un secret Kubernetes

Puoi utilizzare un certificato emesso e convalidato dalla tua autorità di certificazione (CA) o crea 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 tuo di chiave privata, ad esempio private-key.pem. Per ulteriori informazioni, vedi Seleziona o crea una chiave privata.

2. Crea un Apri il file di configurazione 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 della nuova configurazione come 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 Crea un CSR.

4. 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 il file generato dal comando, ad esempio cert-file.pem. Per ulteriori informazioni le informazioni, vedi Firma la richiesta di firma del certificato (CSR).

5. Crea un secret TLS Kubernetes utilizzando la chiave e il file del certificato che creato da te:

   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 un protocollo HTTPRoute

1. 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 e port: 443: obbligatori per attivare TLS.
   • tls: fa riferimento al secret di 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/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 file manifest descrive una route HTTP 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 tramite 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 che l'accesso possa connettersi a quest'ultimo.

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 generati. Devi salvare il file sul computer in uso connettersi al gateway. Il certificato è necessario per autenticare 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 a livello di gateway dell'applicazione risponde al client in modo sicuro.

Proteggi un gateway utilizzando un certificato SSL

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

Nota: configura un certificato SSL e networking.gke.io/certmap l'annotazione sullo stesso gateway non è una configurazione valida e lo considererà un errore.

Crea un certificato SSL

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

1. 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 e port:443: obbligatori per attivare 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/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
   

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

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 che l'accesso possa connettersi a quest'ultimo.

2. Aggiornare un record A o AAAA per indirizzare il dominio all'indirizzo IP del gateway.

   Questo passaggio è necessario solo se stai configurando un protocollo SSL gestito da Google certificato. Se stai configurando un certificato autogestito, puoi saltare questo passaggio.

   Dopo l'aggiornamento dei record DNS, potrebbero essere necessari fino a 10 minuti con il bilanciatore del carico di rete per iniziare a utilizzare il certificato gestito da Google.

3. 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 dal un'applicazione. Il TLS viene terminato correttamente a livello di gateway e l'applicazione risponda al cliente in modo sicuro.

Proteggi un gateway utilizzando Gestore certificati

In questo esempio, configuri un gateway utilizzando Gestore certificati:

Nota: configura un certificato SSL e networking.gke.io/certmap l'annotazione sullo stesso gateway non è una configurazione valida e lo considererà un errore.

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.

1. Per creare un certificato, crea prima una chiave privata e un file di 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 assegna il certificato al 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 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.

1. Crea una chiave privata e un file di 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 tuo certificato, per esempio store-example-com-cert.
• CERTIFICATE_FILE: il nome del file del certificato, ad esempio cert.pem.
• PRIVATE_KEY_FILE: nome del file della chiave privata, ad esempio private-key.pem. Per ulteriori informazioni, vedi Seleziona o crea una chiave privata.
• REGION: il nome della regione in cui ti trovi configurazione del gateway, ad esempio us-central1.

Crea un gateway e un protocollo HTTPRoute

Gateway globale

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/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 e port: 443: obbligatori per attivare TLS.

   Non esiste una sezione TLS perché TLS è configurato con Gestore certificati utilizzando l'annotazione networking.gke.io/certmap.

2. Applica il manifest al cluster:

   kubectl apply -f cert-map-gateway.yaml
   

   Il deployment del gateway da parte di GKE potrebbe richiedere diversi minuti.

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

4. 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 Gestione certificati e certificati gestiti generati da Compute Engine.

1. 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 e port: 443: obbligatori per attivare TLS.
   • options:
     • networking.gke.io/cert-manager-certs : certificati gestiti da Gestore certificati.

   Per creare un gateway interno regionale, nell'esempio precedente, modifica il da gatewayClassName a gke-17-rilb. Questa operazione esegue il deployment il bilanciatore del carico delle applicazioni interno.

2. Applica il manifest al cluster:

   kubectl apply -f external-gateway.yaml
   

3. 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 file manifest descrive una route HTTP che corrisponde al traffico per store.example.com e inoltra il traffico 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 che l'accesso possa connettersi a quest'ultimo.

2. Aggiornare un record A o AAAA per indirizzare il dominio all'indirizzo IP del gateway.

   Questo passaggio è necessario solo se stai configurando un protocollo SSL gestito da Google Certificato. Se stai configurando un certificato autogestito, puoi saltare questo passaggio.

   Dopo l'aggiornamento dei record DNS, potrebbero essere necessari fino a 10 minuti con il bilanciatore del carico di rete per iniziare 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 generati. Devi salvare il file sul computer in uso connettersi al gateway. Il certificato è necessario per autenticare 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 dal un'applicazione. Il TLS viene terminato correttamente a livello di gateway e l'applicazione risponda al cliente 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 campo ports[].appProtocol. I campi supportati per appProtocol sono: HTTP, HTTPS e HTTP2.

Il manifest seguente descrive un servizio che specifica il bilanciatore del carico devono 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

Nota: il campo appProtocol è sensibile alle maiuscole e richiede l'impostazione del valore utilizzando le lettere maiuscole: HTTP, HTTPS o HTTP2. Se usi le lettere minuscole, Il valore predefinito di appProtocol è HTTP.

Il bilanciatore del carico non verifica il certificato utilizzato dai pod di backend. È la tua responsabilità di garantire che il certificato utilizzato nei pod di backend sia valido.

Nota: i networking.gke.io/app-protocol supportati in precedenza sono deprecati. Questa annotazione non è supportata dal controller gateway GKE.

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 Versione SSL o TLS. Puoi proteggere dal client al traffico del bilanciatore del carico utilizzando i criteri SSL.

Per saperne di più sui criteri SSL che possono essere collegati al tuo gateway e su come consulta Configurare i criteri SSL per proteggere il client al traffico del bilanciatore del carico.

Proteggi i tuoi backend con Google Cloud Armor

Criteri di sicurezza di Google Cloud Armor per aiutarti a proteggere le applicazioni con bilanciamento del carico dagli attacchi basati sul web. Una volta 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 la sicurezza di Google Cloud Armor per proteggere i tuoi Servizi di backend.

Autentica le richieste ai tuoi backend utilizzando Identity-Aware Proxy

Identity-Aware Proxy ti aiuta a proteggere i backend da del traffico indesiderato, autenticando i clienti che inviano richieste ai tuoi applicazioni e l'applicazione dell'autorizzazione del traffico basata su ruoli. Dopo l'attivazione Identity-Aware Proxy per GKE, puoi fare riferimento le 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ù su Sicurezza del gateway.