Sicurezza del gateway

Questa pagina descrive diversi metodi per proteggere i gateway in Google Kubernetes Engine (GKE). Puoi anche scoprire come proteggere un gateway.

Come funziona la sicurezza del gateway

Un gateway rappresenta il frontend di un bilanciatore del carico. Esistono due percorsi che puoi proteggere con l'autenticazione e la crittografia per i gateway:

  • Da client a gateway: traffico originato dal client e terminato al gateway.
  • Gateway to Pod: traffico originato dal gateway e terminato nei pod di backend.

Il seguente diagramma mostra entrambi i percorsi per autenticare e criptare i gateway:

Oltre alla crittografia, puoi proteggere il percorso dal client al gateway utilizzando le policy di autorizzazione. Le policy di autorizzazione consentono un'architettura Zero Trust ispezionando le richieste in entrata e applicando controllo dell'accesso in base alle identità dei client, alle intestazioni HTTP e ai percorsi richiesti prima che il traffico venga indirizzato ai pod di backend.

Questa pagina descrive come proteggere il percorso dal client al gateway utilizzando i certificati caricati e gestiti a livello di gateway. Per scoprire come proteggere il traffico da Gateway a pod, consulta Proteggere il traffico dal bilanciatore del carico all'applicazione utilizzando TLS.

Vantaggi

Puoi proteggere un'applicazione in molti modi diversi utilizzando l'API Gateway, che offre flessibilità a diversi ruoli che interagiscono con il gateway.

Chi possiede la configurazione del dominio e di TLS?

Il modello dell'API Gateway introduce due ruoli che utilizzano o eseguono il deployment dei gateway:

  • Amministratore della piattaforma: l'operatore del cluster è l'amministratore di interi cluster. Gestiscono le policy, l'accesso alla rete e le autorizzazioni delle applicazioni.
  • Sviluppatore di applicazioni: lo sviluppatore di applicazioni definisce la propria applicazione e la configurazione del servizio.

Il seguente diagramma mostra i campi nelle risorse Gateway e HTTPRoute che influenzano TLS e la proprietà del dominio per due applicazioni, store-v1 e store-v2.

Nel diagramma, l'operatore del cluster controlla:

  • Quali domini possono essere utilizzati dagli sviluppatori di applicazioni per le loro app in ogni spazio dei nomi.
  • I certificati specifici che terminano domini diversi.
  • Certificati forniti dal proprietario del gateway.
  • Possibilità per i proprietari di HTTPRoute di specificare i propri nomi host per la generazione dei certificati.

Gli sviluppatori di applicazioni controllano il nome host che genera un certificato, se la definizione del gateway lo consente.

Questa separazione delle attività operative consente agli sviluppatori di applicazioni di eseguire il deployment e gestire la propria HTTPRoute per un controllo più distribuito e agli amministratori della piattaforma di eseguire il deployment e gestire i gateway per il controllo centralizzato di TLS.

Gestione dei certificati del gateway

Puoi proteggere i gateway utilizzando uno dei seguenti metodi:

Se utilizzi risorse Kubernetes Secrets o SslCertificate dall'API Compute Engine, puoi collegare al massimo 15 certificati a un singolo gateway.

Certificate Manager ti consente di collegare fino a 10.000.000 di certificati per bilanciatore del carico, se richiedi un aumento della quota.

Per saperne di più sui Cloud de Confiance certificati SSL, consulta Panoramica dei certificati SSL.

Secret Kubernetes

La specifica dell'API Gateway supporta i secret Kubernetes per archiviare e collegare i certificati ai gateway. Puoi associare uno o più secret Kubernetes a un gateway utilizzando il campo Gateway.spec.tls.certificateRef.

Le risorse Gateway protette tramite i secret di Kubernetes hanno i seguenti requisiti:

  • Devi impostare i listener del gateway port e protocol su 443 e HTTPS.
  • Devi impostare il campo listener.tls.mode su Terminate.
  • Devi fare riferimento alle credenziali TLS nel blocco listeners.tls.

Le risorse gateway protette utilizzando i secret Kubernetes presentano le seguenti limitazioni:

  • Solo i listener HTTPS terminano il traffico utilizzando i secret specificati, anche se puoi specificare più listener con una combinazione di HTTP e HTTPS.
  • Se hai più listener che utilizzano HTTPS sullo stesso gateway, ogni listener deve avere un nome host univoco.
  • Puoi omettere un solo nome host o assegnare * per ogni coppia di porta e protocollo.
  • Puoi assegnare un solo certificato predefinito per ogni gateway.

Per scoprire come proteggere un gateway utilizzando un secret di Kubernetes, consulta Proteggere un gateway utilizzando un secret di Kubernetes.

Certificati SSL

I certificati SSL archiviano e forniscono certificati ai bilanciatori del carico. Un certificato SSL può essere autogestito o gestito da Google.

  • I certificati SSL autogestiti sono certificati che ottieni, di cui esegui il provisioning e che rinnovi autonomamente.
  • I certificati SSL gestiti da Google sono certificati che Cloud de Confiance by S3NS ottiene, gestisce e rinnova automaticamente.

Per scoprire di più sulle differenze tra questi due tipi di certificati, consulta la pagina Panoramica dei certificati SSL.

L'ambito e la posizione del certificato SSL devono corrispondere all'ambito e alla posizione del gateway che lo utilizza. Ad esempio, un certificato SSL globale non può essere utilizzato da un gateway regionale.

La tabella seguente elenca i requisiti di ambito e posizione dei certificati SSL per ogni GatewayClass:

GatewayClass Ambito del certificato SSL Posizione del certificato SSL
gke-l7-global-external-managed Certificato SSL globale Globale
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc
gke-l7-regional-external-managed Certificato SSL a livello di regione Deve essere la stessa regione del gateway
gke-l7-regional-external-managed-mc
gke-l7-cross-regional-internal-managed-mc
gke-l7-rilb
gke-l7-rilb-mc

I certificati SSL gestiti da Google non sono compatibili con i gateway regionali. Per proteggere i gateway regionali, utilizza Certificate Manager.

Per scoprire come proteggere un gateway utilizzando un certificato SSL, consulta Proteggi un gateway utilizzando un certificato SSL.

Certificate Manager

Certificate Manager è una posizione centralizzata per gestire i certificati TLS.

Quando proteggi un gateway utilizzando Certificate Manager, puoi fare quanto segue:

  • Fai riferimento a un CertificateMap direttamente da un gateway che hai creato in Certificate Manager.
  • Gestisci i tuoi certificati.
  • Migliorare i tempi di propagazione dei certificati.
  • Utilizza Cloud Monitoring per i certificati scaduti e la propagazione dei certificati.

Certificate Manager supporta i certificati SSL autogestiti e gestiti da Google. Per scoprire come proteggere un gateway utilizzando Certificate Manager, consulta Proteggere un gateway utilizzando Certificate Manager.

Supporto TLS di GatewayClass

La tabella seguente descrive i metodi di terminazione TLS supportati da GKE per ogni GatewayClass:

GatewayClass gke-l7-global-external-managed
gke-l7-global-external-managed-mc
gke-l7-gxlb
gke-l7-gxlb-mc 		gke-l7-regional-external-managed
gke-l7-regional-external-managed-mc
gke-l7-rilb
gke-l7-rilb-mc 		gke-l7-cross-regional-internal-managed-mc
TLS da client a gateway Supportato Supportato
TLS da gateway a backend Supportato Supportato
Cloud de Confiance risorsa certificato Certificato SSL globale
CertificateMap		 Certificato SSL a livello di regione
Certificati autogestiti con i secret Kubernetes Supportato Supportato Non supportato
Certificati SSL autogestiti di Compute Engine Supportato Supportato Non supportato
Certificati SSL di Compute Engine gestiti da Google Supportato Non supportato Non supportato
Certificati SSL autogestiti con Certificate Manager Supportato Supportato Supportato
Certificati SSL gestiti da Google con Certificate Manager Supportato Supportato Supportato

Autorizzazione e controllo dell'accesso

I gateway GKE supportano controllo dell'accesso basato sull'identità utilizzando la risorsa personalizzata GCPAuthzPolicy. Questa risorsa consente agli amministratori della piattaforma di definire regole esplicite ALLOW o DENY per il traffico nord-sud.

Inoltre, i gateway possono integrarsi con Service Extensions utilizzando la risorsa GCPAuthzExtension. Questa risorsa consente al gateway di effettuare callout in linea a motori di autorizzazione esterni, personalizzati o di terze parti (come Identity-Aware Proxy) per valutare le richieste in tempo reale.

Passaggi successivi