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

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 client-gateway e gateway-backend con TLS
Policy 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
Policy di autorizzazione per applicare controllo dell'accesso basato sull'identità e l'architettura zero trust a livello di gateway

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

Per 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 GKE Gateway Controller

L'API Gateway è supportata solo sui cluster nativi di VPC.
Se utilizzi le GatewayClass a livello di regione o tra regioni, devi attivare una subnet solo proxy.
Il componente aggiuntivo HttpLoadBalancing deve essere abilitato nel cluster.
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 necessario, crea un cluster Autopilot.

Restrizioni e limitazioni

Oltre alle restrizioni e 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 di Kubernetes come soluzione alternativa per questa versione di GKE.
Non puoi utilizzare l'annotazione networking.gke.io/certmap con un tls.certificateRefs sulla stessa risorsa Gateway. Se fai riferimento a una mappa dei certificati 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 a livello di regione e i gateway globali.
Quando utilizzi i certificati SSL gestiti da Google, devi crearli 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 nel tuo GCPBackendPolicy. Per questo caso d'uso, devi creare due servizi e policy separati.
Il controller del gateway non supporta la risorsa ManagedCertificate.
Il controller del gateway non supporta l'annotazione networking.gke.io/managed-certificates.
Se configuri Cloud CDN con il gateway GKE, non puoi abilitare sia IAP sia Cloud CDN con lo stesso gateway, incluse le singole route con Cloud CDN. Se devi abilitare Cloud CDN per una route che utilizza una risorsa GCPHTTPFilter, devi prima rimuovere qualsiasi risorsa GCPBackendPolicy esistente che configura IAP per quel gateway.
Quota TrustConfig. Per informazioni sulla dimensione totale di tutte le risorse TrustConfig in ogni località, consulta Quote e limiti delle risorse.
Allineamento della posizione. La risorsa TrustConfig a cui viene fatto riferimento deve trovarsi nella stessa località (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 dell'API Gateway supportati e delle funzionalità delle risorse GatewayClass disponibili su GKE, consulta Funzionalità di GatewayClass.

Proteggi un gateway utilizzando un secret di Kubernetes

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

Archivia un certificato in un secret di 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.

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 Seleziona o crea una chiave privata.

Crea un file di configurazione OpenSSL:

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.

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 saperne di più, consulta Crea una CSR.

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 saperne di più, consulta Firma la CSR.

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

Crea un gateway e una risorsa HTTPRoute

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

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.

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.

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 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é quest'ultimo 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 TLS handshake riuscito seguito da una risposta dell'applicazione. La connessione TLS viene terminata nel 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 una risorsa HTTPRoute

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 tuo certificato SSL.

Applica il manifest al tuo cluster:
```
kubectl apply -f external-gateway.yaml
```

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

Esegui il deployment di HTTPRoute nel tuo 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.
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.

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 TLS handshake riuscito e una risposta dall'applicazione. Il protocollo TLS viene terminato correttamente nel gateway e l'applicazione risponde al client in modo sicuro.

Proteggi un gateway utilizzando Certificate Manager

In questo esempio, configuri un gateway utilizzando Certificate Manager.

Crea un certificato

Gateway globale

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.

Per creare un certificato, devi prima creare un file di chiave privata e 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 una risorsa CertificateMapEntry che assegna il certificato alla risorsa 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, devi creare un certificato 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 un file di chiave privata e certificato.
Crea una risorsa Certificate caricando il file e la chiave del certificato:

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 Seleziona o crea una chiave privata.
REGION: il nome della regione in cui stai configurando il gateway, ad esempio us-central1.

Crea un gateway e una risorsa 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/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 esiste una sezione TLS perché TLS è configurato con Certificate Manager 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 risorsa 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

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 Certificate Manager e i certificati gestiti da Compute Engine.

Per creare un gateway esterno a livello di regione, 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. In questo modo viene eseguito il deployment di un bilanciatore del carico delle applicazioni interno.

Applica il manifest al cluster:
```
kubectl apply -f external-gateway.yaml
```

Per creare una risorsa 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.

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

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 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é quest'ultimo 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 TLS handshake riuscito e una risposta dall'applicazione. Il protocollo TLS viene terminato correttamente nel gateway e l'applicazione risponde al client in modo sicuro.

Configura mTLS frontend per un gateway

Puoi configurare la convalida del certificato client, nota anche come mTLS frontend, per il gateway GKE.

mTLS frontend è supportato per le seguenti GatewayClass:

gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb-mc

mTLS frontend consente al gateway di autenticare i certificati presentati dai client ed è valido per i listener HTTPS che utilizzano la modalità Terminate.

Puoi configurare mTLS frontend in uno dei seguenti modi:

Utilizza la configurazione dell'API Gateway (consigliato).
Utilizza un'annotazione TrustConfig autogestita sul gateway (opzione avanzata).

Configura mTLS frontend utilizzando la configurazione dell'API Gateway (consigliato)

L'utilizzo dell'API Gateway è il modo consigliato per configurare la convalida dei certificati client. Questo metodo prevede l'archiviazione delle origini di attendibilità in un ConfigMap di Kubernetes e il riferimento a questo ConfigMap nella specifica del gateway.

Crea origini di attendibilità.

Le origini attendibili stabiliscono e convalidano la radice di attendibilità per i certificati client presentati al bilanciatore del carico. Il gateway GKE supporta le origini di attendibilità basate su certificati radice.

Per creare i certificati, consulta Crea i certificati root e intermedi.
Crea un ConfigMap.

Archivia le tue origini di attendibilità in un oggetto ConfigMap di Kubernetes. Ogni chiave in ConfigMap deve contenere esattamente un certificato CA con codifica PEM in un formato x509 valido. Devi creare questo ConfigMap nello stesso spazio dei nomi della risorsa Gateway, a meno che non utilizzi un ReferenceGrant. Per fare riferimento a un ConfigMap in uno spazio dei nomi diverso, consulta ReferenceGrant.

Inserisci i dati del certificato sotto la chiave ca.crt:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-cert
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    <PEM_DATA>
    -----END CERTIFICATE-----
```
Nota: puoi fare riferimento a un massimo di otto risorse ConfigMap per configurazione (nella configurazione predefinita o per porta). Quando utilizzi un ConfigMap, sono supportati solo i certificati radice. Per utilizzare certificati intermedi o consentiti, devi utilizzare una risorsa TrustConfig autogestita.

Per creare un ConfigMap con i tuoi certificati, esegui questo comando:
```
kubectl create configmap my-config \
    --from-file=ca.crt=ROOT_CERT_PATH
```
Sostituisci ROOT_CERT_PATH con il percorso del file del certificato. Un ConfigMap può contenere un solo certificato.

Configura il gateway.

Collega ConfigMap al gateway aggiungendo una sezione tls contenente il campo frontend.default.validation alla specifica del gateway. La configurazione default è obbligatoria e si applica a tutti i listener HTTPS che utilizzano la modalità Terminate, a meno che non specifichi una configurazione per porta. L'esempio seguente mostra una configurazione end-to-end del gateway che include sia un certificato server (utilizzando l'annotazione certmap) sia la convalida del certificato client (utilizzando il campo tls.frontend.default.validation):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mtls-example
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  gatewayClassName: gke-l7-global-external-managed
  tls:
    frontend:
      default:
        validation:
          caCertificateRefs:
          - kind: ConfigMap
            group: ""
            name: my-config
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      mode: Terminate
      # No certificateRefs needed when using the certmap annotation

Esegui l'override della configurazione per porta.

Puoi anche specificare origini di attendibilità univoche per singole porte. Una configurazione per porta sostituisce la configurazione predefinita per tutti i listener configurati per quella porta.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mtls-port-override
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  gatewayClassName: gke-l7-global-external-managed
  tls:
    frontend:
      default:
        validation:
          caCertificateRefs:
          - kind: ConfigMap
            group: ""
            name: global-ca-config
      perPort:
      - port: 8443
        tls:
          validation:
            caCertificateRefs:
            - kind: ConfigMap
              group: ""
              name: port-specific-ca-config
  listeners:
  - name: https-default
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
  - name: https-override
    protocol: HTTPS
    port: 8443
    tls:
      mode: Terminate

(Facoltativo) Configura la modalità di convalida client.

Per impostazione predefinita, i gateway GKE applicano una convalida rigorosa dei certificati client (AllowValidOnly). Per consentire certificati client non validi o mancanti, nella configurazione frontend.default.validation, imposta il valore della chiave mode su AllowInsecureFallback:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mtls-example
  annotations:
    networking.gke.io/certmap: store-example-com-map # Add this annotation
spec:
  gatewayClassName: gke-l7-global-external-managed
  tls:
    frontend:
      default:
        validation:
          caCertificateRefs:
          - kind: ConfigMap
            group: ""
            name: my-config
          mode: AllowInsecureFallback
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      mode: Terminate
      # No certificateRefs needed when using the certmap annotation

Utilizza un TrustConfig autogestito (opzione avanzata)

In alternativa, configura la convalida del certificato client annotando il gateway con una risorsa TrustConfig. Utilizza questo metodo autogestito se hai bisogno di maggiore flessibilità o se la tua configurazione supera i limiti standard dell'API Gateway. Questo metodo si esclude a vicenda con il metodo di configurazione dell'API Gateway e si applica a tutti i listener HTTPS sul gateway (gli override per porta non sono supportati).

Crea una risorsa TrustConfig. Per le istruzioni, consulta Crea una risorsa di configurazione di attendibilità.

Quando crei la risorsa TrustConfig, specifica global per i gateway globali (gke-l7-global-external-managed) e tutti i gateway multi-cluster (gke-l7-global-external-managed-mc, gke-l7-regional-external-managed-mc, gke-l7-cross-regional-internal-managed-mc e gke-l7-rilb-mc) o la regione appropriata (ad esempio us-central1) per i gateway regionali (gke-l7-regional-external-managed e gke-l7-rilb).

Collega TrustConfig al gateway utilizzando l'annotazione networking.gke.io/frontend-trust-config.

L'esempio seguente mostra una configurazione end-to-end del gateway che include sia un certificato server (utilizzando l'annotazione certmap) sia la convalida del certificato client (utilizzando l'annotazione TrustConfig):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mtls-example
  annotations:
    networking.gke.io/frontend-trust-config: my-trust-config
    networking.gke.io/certmap: store-example-com-map # Add this annotation
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      mode: Terminate
      # Remove certificateRefs and replace with the comment
      # No certificateRefs needed when using the certmap annotation

(Facoltativo) Configura la modalità di convalida client.

Per impostazione predefinita, i gateway GKE applicano una convalida rigorosa dei certificati client (REJECT_INVALID). Per consentire certificati client non validi o mancanti, imposta l'annotazione networking.gke.io/allow-invalid-or-missing-client-cert su true.

Configura TLS di backend per un gateway

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

Puoi configurare TLS autenticato dal backend utilizzando una risorsa BackendTLSPolicy collegata a un servizio, InferencePool, ServiceImport o GCPInferencePoolImport. La risorsa BackendTLSPolicy deve trovarsi nello stesso spazio dei nomi della risorsa di destinazione.

TLS di backend è supportato per le seguenti GatewayClass:

gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb
gke-l7-rilb-mc

Configura mTLS di backend per un gateway

Mutual TLS (mTLS) del backend è una funzionalità basata su TLS autenticato dal backend. Sebbene il TLS autenticato dal backend verifichi l'identità dei pod di backend per il bilanciatore del carico, l'mTLS di backend consente al bilanciatore del carico del gateway GKE di autenticare anche la propria identità per i pod di backend presentando un certificato client. Devi configurare TLS autenticato dal backend nell'ambito della configurazione di mTLS di backend.

Il gateway GKE configura mTLS di backend utilizzando il campo spec.tls.backend.clientCertificateRef dell'API Gateway standard.

mTLS di backend è supportato per le seguenti GatewayClass:

gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb-mc

Per configurare mTLS di backend, completa i seguenti passaggi:

Archivia il certificato client e la chiave privata in un secret Kubernetes standard.
Fai riferimento al secret del certificato client nella specifica della risorsa Gateway.
Configura TLS autenticato dal backend utilizzando una risorsa BackendTLSPolicy che ha come target il tuo servizio.

Passaggio 1: memorizza le credenziali del client

Prima di archiviare le credenziali del client, assicurati che il certificato sia conforme ai requisiti dei certificati.

Per archiviare il certificato client e la chiave privata in un secret TLS Kubernetes standard nello stesso spazio dei nomi della risorsa Gateway, esegui questo comando:

kubectl create secret tls gateway-client-identity \
    --cert=PATH_TO_CERT_FILE \
    --key=PATH_TO_KEY_FILE \
    --namespace=default

Sostituisci i seguenti valori:

PATH_TO_CERT_FILE: il percorso del file del certificato client in formato PEM.
PATH_TO_KEY_FILE: il percorso del file della chiave privata in formato PEM.

Passaggio 2: fai riferimento alle credenziali client nel gateway

Per fare riferimento al secret del certificato client nel blocco spec.tls.backend della risorsa Gateway, salva il seguente manifest come my-gateway.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: gke-l7-global-external-managed
  tls:
    backend:
      clientCertificateRef:
        group: "" # empty group resolves to Core API
        kind: Secret
        name: gateway-client-identity
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate

Applica il manifest al cluster:
```
kubectl apply -f my-gateway.yaml
```

Passaggio 3: applica BackendTLSPolicy

Per convalidare l'identità del server di backend, devi applicare una risorsa BackendTLSPolicy che abbia come target il servizio a cui fa riferimento la risorsa HTTPRoute.

Per istruzioni dettagliate e manifest su come configurare TLS autenticato dal backend, consulta Configura TLS del backend per un gateway.

Utilizza un ConfigMap Kubernetes (standard)

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

Crea una risorsa ConfigMap contenente i certificati CA con codifica PEM. Per saperne di più, 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 risorsa BackendTLSPolicy supporta il riferimento a un massimo di otto risorse ConfigMap nel campo caCertificateRefs.

I dati del certificato devono essere inseriti nella 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.

Scegli come target un servizio, un InferencePool, un ServiceImport o un GCPInferencePoolImport con un BackendTLSPolicy che fa riferimento al ConfigMap:

Servizio

Il seguente manifest mostra una risorsa 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 un 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 un 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 un 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

Utilizza un TrustConfig autogestito (opzione avanzata)

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

Crea una risorsa TrustConfig in Certificate Manager. La risorsa TrustConfig deve essere creata nello stesso progetto e nella stessa località del gateway.
- Per i gateway globali o multi-cluster (inclusi i multi-cluster regionali) e i gateway tra regioni, utilizza la località global.
- Per i gateway regionali a cluster singolo, utilizza la stessa regione del gateway.
- Se il tuo servizio viene utilizzato da più gateway in località diverse, devi creare una risorsa TrustConfig con lo stesso nome in ciascuna di queste località.

Scegli 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"

Riferimento ai campi di 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 le GatewayClass `gke-l7-global-external-managed` e `gke-l7-global-external-managed-mc`, sono supportati solo i backend Service e ServiceImport.
`validation.hostname`	Il nome host (SNI) utilizzato dal gateway durante il TLS handshake 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 le 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 la risorsa BackendTLSPolicy, verifica che il controller del gateway abbia accettato la configurazione controllando lo stato secondo le norme della policy:

kubectl describe backendtlspolicy POLICY_NAME

Sostituisci POLICY_NAME con il nome della policy.

Una policy viene applicata 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 di queste condizioni, significa che la policy non è stata applicata. Per ulteriori dettagli, controlla i campi Reason e Message. Gli errori comuni includono il riferimento a un ConfigMap in caCertificateRefs che non esiste o in 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 dell'InferencePool di destinazione. La risorsa BackendTLSPolicy deve trovarsi nello stesso spazio dei nomi della risorsa di destinazione.

Proteggi il traffico dal bilanciatore del carico all'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 Service 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 controller GKE Gateway non gestisce il certificato utilizzato dai pod di backend. È tua responsabilità assicurarti che il certificato utilizzato sui pod di backend sia valido.

Proteggi il traffico dal client al bilanciatore del carico utilizzando le policy 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ù sulle policy SSL che possono essere collegate al tuo gateway e su come crearle, consulta Configura le policy SSL per proteggere il traffico dal client al bilanciatore del carico.

Proteggi i tuoi backend utilizzando Google Cloud Armor

Le policy 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 di Google Cloud Armor, puoi farvi riferimento in un GCPBackendPolicy applicato ai tuoi servizi Kubernetes.

Per configurare le policy di Google Cloud Armor con Gateway, consulta Configura la policy 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 ti aiuta a proteggere i tuoi 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 Gateway, consulta Configura Identity-Aware Proxy.

Configura la condivisione di risorse multiorigine (CORS)

La condivisione delle risorse multiorigine (CORS) è un meccanismo di sicurezza che aiuta le applicazioni web in esecuzione in un'origine (dominio) ad accedere in modo sicuro alle risorse ospitate in un'origine diversa. Puoi configurare le policy CORS direttamente nelle risorse HTTPRoute utilizzando il filtro CORS. Quando configuri il filtro CORS, il gateway GKE scarica la risposta alle richieste preflight (OPTIONS) e l'inserimento delle intestazioni della risposta CORS dal codice dell'applicazione.

Per saperne di più su come configurare il filtro CORS e sui campi supportati, consulta Configura la condivisione delle risorse multiorigine (CORS).

Applica controllo dell'accesso utilizzando le policy di autorizzazione

Puoi applicare controllo dell'accesso granulare basato sull'identità al traffico che entra nel tuo gateway utilizzando le policy di autorizzazione (GCPAuthzPolicy). Questa policy consente di definire regole per ALLOW o DENY le richieste in base all'identità di origine (ad esempio il nome alternativo del soggetto o il nome comune di un certificato client), al percorso di destinazione o a intestazioni HTTP specifiche.

Per scenari di sicurezza avanzati, puoi delegare le decisioni di autorizzazione a servizi esterni o motori di terze parti (come un web application firewall personalizzato) utilizzando un'estensione dell'autorizzazione (GCPAuthzExtension).

Configura una policy di autorizzazione `ALLOW`

L'esempio seguente descrive una policy di autorizzazione che si applica a un gateway nello spazio dei nomi default. La policy limita l'accesso consentendo solo le richieste ai percorsi /home e /public, il che nega implicitamente l'accesso a tutti gli altri percorsi.

Salva il seguente manifest in allow-policy.yaml:

apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-paths
  namespace: default
spec:
  enforcementLevel: L7
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: "GATEWAY_NAME"
  action: ALLOW
  rules:
  - to:
      operations:
      - paths:
        - type: Exact
          value: "/home"
        - type: Exact
          value: "/public"

Sostituisci GATEWAY_NAME con il nome del tuo gateway.

Applica il manifest:
```
kubectl apply -f allow-policy.yaml
```

Configura una policy di autorizzazione `DENY`

L'esempio seguente descrive una policy di autorizzazione che si applica a un gateway nello spazio dei nomi default. La policy nega esplicitamente tutte le richieste al percorso /private, consentendo l'accesso a tutti gli altri percorsi per impostazione predefinita.

Salva il seguente manifest in deny-policy.yaml:

apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: deny-path
  namespace: default
spec:
  enforcementLevel: L7
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: "GATEWAY_NAME"
  action: DENY
  rules:
  - to:
      operations:
      - paths:
        - type: Exact
          value: "/private"

Sostituisci GATEWAY_NAME con il nome del tuo gateway.

Applica il manifest:
```
kubectl apply -f deny-policy.yaml
```

Passaggi successivi

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

Proteggere un gateway Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

Requisiti del GKE Gateway Controller

Restrizioni e limitazioni

Proteggi un gateway utilizzando un secret di Kubernetes

Archivia un certificato in un secret di Kubernetes

Crea un gateway e una risorsa HTTPRoute

Verifica il gateway

Proteggi un gateway utilizzando un certificato SSL

Crea un certificato SSL

Crea un gateway e una risorsa HTTPRoute

Verifica il gateway

Proteggi un gateway utilizzando Certificate Manager

Crea un certificato

Gateway globale

Gateway regionale

Crea un gateway e una risorsa HTTPRoute

Gateway globale

Gateway regionale

Verifica il gateway

Configura mTLS frontend per un gateway

Configura mTLS frontend utilizzando la configurazione dell'API Gateway (consigliato)

Utilizza un TrustConfig autogestito (opzione avanzata)

Configura TLS di backend per un gateway

Configura mTLS di backend per un gateway

Passaggio 1: memorizza le credenziali del client

Passaggio 2: fai riferimento alle credenziali client nel gateway

Passaggio 3: applica BackendTLSPolicy

Utilizza un ConfigMap Kubernetes (standard)

Servizio

InferencePool

ServiceImport

GCPInferencePoolImport

Utilizza un TrustConfig autogestito (opzione avanzata)

Riferimento ai campi di BackendTLSPolicy

Verifica la configurazione TLS del backend

Proteggi il traffico dal bilanciatore del carico all'applicazione utilizzando TLS

Proteggi il traffico dal client al bilanciatore del carico utilizzando le policy SSL

Proteggi i tuoi backend utilizzando Google Cloud Armor

Autentica le richieste ai tuoi backend utilizzando Identity-Aware Proxy

Configura la condivisione di risorse multiorigine (CORS)

Applica controllo dell'accesso utilizzando le policy di autorizzazione

Configura una policy di autorizzazione ALLOW

Configura una policy di autorizzazione DENY

Passaggi successivi

Proteggere un gateway

Configura una policy di autorizzazione `ALLOW`

Configura una policy di autorizzazione `DENY`