Best practice per l'utilizzo dei gateway in uscita di Cloud Service Mesh su cluster GKE

Questo documento descrive come utilizzare i gateway di uscita di Cloud Service Mesh e altri controlli di Google Cloud per proteggere il traffico in uscita (di uscita) dai carichi di lavoro di cui è stato eseguito il deployment in un cluster Google Kubernetes Engine (GKE). Questi controlli possono limitare le connessioni ai servizi esterni in base all'identità dell'applicazione di origine, allo spazio dei nomi di un team, al dominio di destinazione e ad altre proprietà delle richieste in uscita.

Il pubblico di destinazione di questo documento include tecnici di rete, della piattaforma e della sicurezza che amministrano i cluster GKE utilizzati da uno o più team di distribuzione del software. I controlli descritti qui potrebbero essere particolarmente utili per le organizzazioni che devono dimostrare la conformità alle normative (ad esempio, GDPR e PCI).

Introduzione

L'approccio tradizionale alla sicurezza di rete è stato quello di definire perimetri di sicurezza attorno a un gruppo di applicazioni. I firewall vengono utilizzati in questi perimetri per consentire o negare il traffico in base agli indirizzi IP di origine e di destinazione, garantendo al contempo l'attendibilità delle applicazioni e del traffico contenuti nel perimetro. Tuttavia, questa fiducia comporta dei rischi. Un insider malintenzionato o chiunque comprometta il perimetro può muoversi liberamente all'interno della rete, accedere ai dati e estrarli, attaccare sistemi di terze parti e interferire con i sistemi di amministrazione.

Quando i carichi di lavoro in esecuzione su un cluster Kubernetes effettuano connessioni in uscita con host su internet, l'applicazione di controlli di sicurezza tradizionali basati su IP può essere complicata perché:

• Gli indirizzi IP dei pod non rappresentano adeguatamente l'identità del workload che esegue la connessione. In un ambiente Kubernetes, gli indirizzi IP dei pod vengono assegnati in modo temporaneo e vengono riciclati di frequente man mano che i pod vengono creati e eliminati.

• Spesso è impossibile identificare un insieme piccolo e fisso di indirizzi IP per determinati host di destinazione. Gli indirizzi IP cambiano spesso, variano in base alla regione e possono essere presi da intervalli ampi o rappresentare cache, proxy o CDN.

• Più team che condividono lo stesso cluster multi-tenant, con un intervallo di indirizzi IP di origine condivisi, potrebbero avere requisiti di connettività esterna diversi.

Cloud Service Mesh è un mesh di servizi completamente gestito su Google Cloud basato sul mesh di servizi open source Istio. Un mesh di servizi consente di connettere, gestire e proteggere in modo uniforme la comunicazione tra le applicazioni. Le mesh di servizi adottano un approccio incentrato sulle applicazioni e utilizzano identità di applicazioni attendibili anziché un approccio basato su IP di rete.

Puoi eseguire il deployment di un mesh di servizi in modo trasparente senza dover modificare il codice dell'applicazione esistente. L'utilizzo di un mesh di servizi consente di disaccoppiare il lavoro dei team di sviluppo incaricati di fornire e rilasciare le funzionalità dell'applicazione dalle responsabilità degli amministratori di rete, fornendo un controllo dichiarativo del comportamento della rete.

Cloud Service Mesh offre la possibilità di eseguire il deployment di proxy in avanti autonomi,noti come gateway in uscita, sul perimetro del mesh. Questa guida spiega come le funzionalità del proxy del gateway in uscita possono essere combinate con le funzionalità di Google Cloud per controllare, autorizzare e osservare il traffico in uscita dai carichi di lavoro di cui è stato eseguito il deployment in un cluster GKE.

Architettura di difesa in profondità

Il diagramma seguente mostra un'architettura che adotta un approccio di difesa in profondità per il controllo granulare del traffico in uscita per un cluster utilizzato da più team. I controlli si basano sia su quelli di rete di livello 4 (di trasporto) sia su quelli di livello 7 (di applicazione).

L'architettura utilizza le seguenti risorse e controlli:

• Un cluster GKE privato: i nodi di un cluster GKE privato hanno solo indirizzi IP interni e non sono connessi a internet per impostazione predefinita.

• Cloud NAT: Cloud NAT consente l'accesso a internet in uscita dal cluster privato.

• Regole firewall Virtual Private Cloud (VPC): configuri le regole firewall VPC per applicare i controlli di livello 4 (trasporto) alle connessioni da e verso i nodi del cluster GKE. Puoi applicare regole firewall VPC alle VM in base agli account di servizio o ai tag di rete.

• Pool di nodi GKE con account di servizio diversi: ti consente di configurare regole di firewall diverse da applicare in base al pool di nodi a cui appartiene un nodo.

• namespaces Kubernetes: crea spazi dei nomi per ogni team per fornire isolamento e controllo amministrativo delegato. Gli amministratori di rete utilizzano un ambito del nome dedicato per eseguire il deployment del gateway in uscita e per configurare il routing verso gli host esterni.

• Criteri di rete di Kubernetes: i criteri di rete ti consentono di applicare controlli di livello 4 ai pod. Ogni criterio di rete ha ambito in uno spazio dei nomi e può essere definito in modo più granulare per determinati pod in uno spazio dei nomi.

• Un gateway in uscita: il traffico che esce dai pod all'interno del mesh viene indirizzato tramite proxy gateway in uscita dedicati in esecuzione su nodi dedicati. Esegui il deployment di gateway di uscita con un gestitore della scalabilità automatica dei pod orizzontale in modo che il numero di repliche aumenti e diminuisca in base al traffico.

• Criteri di autorizzazione: utilizzi i criteri di autorizzazione del mesh per applicare controlli di livello 7 (applicazione) al traffico tra i pod all'interno del mesh e al traffico in uscita dal mesh.

• Risorse sidecar: utilizza le risorse sidecar per controllare l'ambito di configurazione dei proxy sidecar in esecuzione in ogni pod del carico di lavoro. Puoi utilizzare la risorsa Sidecar per configurare i namespace, i pod e i servizi esterni visibili a un carico di lavoro.

• Accesso privato a Google: Questa opzione consente ai nodi e ai pod del cluster privato di accedere alle API di Google e di estrarre le immagini Docker da Container Registry.

• Workload Identity di GKE: con Workload Identity, puoi utilizzare Identity and Access Management (IAM) per concedere autorizzazioni API a carichi di lavoro specifici seguendo il principio del privilegio minimo, senza dover gestire i secret.

Configurazione dei controlli in uscita

Se utilizzi il gateway in uscita per proteggere il traffico in uscita dal tuo mesh, ti consigliamo di configurare i controlli di difesa in profondità descritti in questa sezione.

Utilizzare GKE privato con Cloud NAT

Quando la sicurezza è importante, il primo requisito di molte organizzazioni è evitare di assegnare indirizzi IP pubblici ai loro carichi di lavoro. Un cluster GKE privato soddisfa questo requisito. Puoi configurare la modalità VPC Native nel tuo cluster privato in modo che ai pod e ai servizi vengano assegnati indirizzi IP dagli intervalli secondari nel VPC. Gli indirizzi IP dei pod VPC nativi sono instradabili in modo nativo all'interno della rete VPC.

Alcuni carichi di lavoro potrebbero richiedere l'accesso a servizi esterni alla rete VPC e a internet. Per consentire ai workload di connettersi a host esterni senza doverli dotare di indirizzi IP pubblici, configura Cloud NAT per fornire la Network Address Translation (NAT).

Assicurati che Cloud NAT sia configurato in modo che il gateway di uscita possa effettuare un numero sufficiente di connessioni simultanee alle destinazioni esterne. Puoi evitare l'esaurimento delle porte e i problemi relativi ai ritardi di riutilizzo della connessione impostando in modo appropriato il numero minimo di porte per VM. Per ulteriori dettagli, consulta la panoramica dell'indirizzo e della porta Cloud NAT. Aumentare il numero di repliche del gateway in uscita può contribuire a ridurre le probabilità di conflitti di mappatura indipendente dagli endpoint.

Configurare l'accesso privato Google per le API e i servizi Google

È probabile che i tuoi carichi di lavoro debbano avere accesso alle API e ai servizi Google. Utilizza l'accesso privato Google con le zone DNS personalizzate per consentire la connettività dalle sottoreti VPC private alle API di Google utilizzando un insieme di quattro indirizzi IP. Quando utilizzi questi indirizzi IP, non è necessario che i pod abbiano indirizzi IP esterni e il traffico non esce mai dalla rete di Google. Puoi utilizzare private.googleapis.com (199.36.153.8/30) o restricted.googleapis.com (199.36.153.4/30), a seconda che tu stia utilizzando Controlli di servizio VPC.

Utilizza Workload Identity e IAM per aumentare la sicurezza delle API e dei servizi Google

L'utilizzo di Workload Identity è il modo consigliato per consentire ai workload GKE di autenticarsi con le API di Google e per consentire agli amministratori di applicare controlli di autorizzazione "del privilegio minimo" utilizzando IAM.

Quando utilizzi l'accesso privato Google, Workload Identity e IAM, puoi consentire in sicurezza ai pod di lavoro di bypassare il gateway di uscita e connettersi direttamente alle API e ai servizi Google.

Utilizzare gli spazi dei nomi Kubernetes per il controllo amministrativo

Gli spazi dei nomi sono una risorsa organizzativa utile in ambienti con molti utenti, team o tenant. Possono essere considerati come un cluster virtuale e consentono di delegare a diversi amministratori la responsabilità amministrativa per gruppi di risorse Kubernetes.

Gli spazi dei nomi sono una funzionalità importante per l'isolamento del controllo amministrativo. Tuttavia, per impostazione predefinita, non forniscono isolamento dei nodi, isolamento del piano dati o isolamento della rete.

Cloud Service Mesh si basa sugli spazi dei nomi Kubernetes utilizzandoli come unità di tenancy all'interno di un mesh di servizi. I criteri di autorizzazione del mesh e le risorse sidecar possono limitare la visibilità e l'accesso in base agli attributi dello spazio dei nomi, dell'identità e del livello 7 (applicazione) del traffico di rete.

Analogamente, puoi utilizzare i criteri di rete di Kubernetes per consentire o negare le connessioni di rete a livello 4 (di trasporto).

Esegui i gateway in uscita su nodi gateway dedicati

L'esecuzione di gateway di uscita sui nodi di un pool di nodi gateway dedicato offre diversi vantaggi. I nodi esposti all'esterno possono utilizzare una configurazione rafforzata e puoi configurare le regole del firewall VPC per impedire ai workload di raggiungere direttamente gli host esterni. I pool di nodi possono essere scalati automaticamente in modo indipendente utilizzando il gestore della scalabilità automatica del cluster.

Per consentire il controllo amministrativo separato del gateway in uscita, esegui il deployment in uno spazio dei nomi istio-egress dedicato. Tuttavia, gli spazi dei nomi sono una risorsa a livello di cluster e non è possibile utilizzarli per controllare su quali nodi viene eseguito il deployment. Per il controllo del deployment, utilizza un selettore di nodi per il deployment del gateway in uscita in modo che venga eseguito sui nodi etichettati come componenti del pool di nodi del gateway.

Assicurati che solo i pod gateway possano essere eseguiti sui nodi gateway. Gli altri pod devono essere allontanati dai nodi gateway, altrimenti i controlli in uscita potrebbero essere aggirati. L'esecuzione dei carichi di lavoro su determinati nodi può essere impedita utilizzando incompatibilità e tolleranze. Devi contaggiare i nodi nel pool di nodi del gateway e aggiungere una tolleranza corrispondente al deployment del gateway in uscita.

Importante: limita la tolleranza del deployment del gateway di uscita in modo che i carichi di lavoro non possano essere dipioyed nei nodi del gateway. Le opzioni per limitare l'uso delle tolleranze sono descritte più avanti in questa guida.

Applicare regole firewall VPC a nodi specifici

Configura il routing di mesh di servizi per indirizzare il traffico in uscita dai carichi di lavoro in esecuzione nel pool di nodi predefinito tramite i gateway in uscita in esecuzione nel pool di nodi del gateway. Tuttavia, la configurazione di routing del mesh non deve essere considerata attendibile come confine di sicurezza perché esistono vari modi in cui un carico di lavoro può aggirare i proxy del mesh.

Per impedire ai workload delle applicazioni di connettersi direttamente ad host esterni, applica regole firewall in uscita restrittive ai nodi del pool di nodi predefinito. Applica regole firewall separate ai nodi gateway in modo che gli pod gateway in uscita in esecuzione su questi nodi possano connettersi a host esterni.

Quando crei una regola firewall VPC, specifichi le porte e i protocolli consentiti o vietati dalla regola firewall e la direzione del traffico a cui si applica. Le regole in uscita si applicano al traffico in uscita e quelle in entrata al traffico in entrata. Il valore predefinito per l'uscita è allow e il valore predefinito per l'ingresso è deny.

Le regole firewall vengono applicate in base a un numero di priorità che puoi specificare. Le regole firewall sono stateful, il che significa che se è consentito un traffico specifico da una VM, è consentito anche il traffico di ritorno che utilizza la stessa connessione.

Il seguente diagramma mostra come è possibile applicare regole firewall separate ai nodi in due pool di nodi diversi in base all'account di servizio assegnato a un nodo. In questo caso, una regola firewall deny all predefinita nega l'accesso in uscita per l'intera VPC. Per evitare di sostituire le regole firewall predefinite essenziali per il funzionamento del cluster, la regola deny all deve utilizzare una priorità bassa, ad esempio 65535. Ai nodi gateway viene applicata una regola firewall in uscita additiva e con priorità più elevata per consentire loro di connettersi direttamente agli host esterni sulle porte 80 e 443. Il pool di nodi predefinito non ha accesso agli host esterni.

Utilizzare i criteri di rete di Kubernetes come firewall per pod e spazi dei nomi

Utilizza i criteri di rete Kubernetes per applicare un ulteriore livello di sicurezza nell'ambito di una strategia di difesa in profondità. I criteri di rete hanno come ambito gli spazi dei nomi e operano a livello 4 (di trasporto). Con i criteri di rete, puoi limitare il traffico in entrata e in uscita:

• Tra spazi dei nomi
• Ai pod all'interno di uno spazio dei nomi
• A porte e blocchi IP specifici.

Dopo che un criterio di rete seleziona i pod in uno spazio dei nomi, tutte le connessioni non consentite esplicitamente vengono rifiutate. Quando vengono applicati più criteri di rete, il risultato è additivo e rappresenta l'unione dei criteri. L'ordine in cui vengono applicati i criteri non è importante.

Ecco alcuni esempi di criteri di rete:

• Consenti le connessioni in uscita dagli spazi dei nomi dei carichi di lavoro agli spazi dei nomi istio-system e istio-egress. I pod devono essere in grado di connettersi al control plane e al gateway in uscita.
• Consenti ai carichi di lavoro di eseguire query DNS dagli spazi dei nomi dei carichi di lavoro alla porta 53 nello spazio dei nomi kube-system.
• Facoltativamente, consenti ai carichi di lavoro nello stesso spazio dei nomi di connettersi tra loro.
• Facoltativamente, consenti le connessioni in uscita tra gli spazi dei nomi utilizzati da diversi team di applicazioni.
• Consenti le connessioni in uscita dai namespace dei carichi di lavoro ai VIP per le API di Google (esposte utilizzando l'accesso privato Google). Cloud Service Mesh fornisce una CA gestita e la espone come API, pertanto i proxy sidecar devono essere in grado di connettersi. È inoltre probabile che alcuni carichi di lavoro debbano accedere alle API Google.
• Consenti le connessioni in uscita dagli spazi dei nomi dei carichi di lavoro al server di metadati GKE in modo che i proxy sidecar e i carichi di lavoro possano eseguire query sui metadati e autenticarsi alle API di Google.

Per impostazione predefinita, quando un proxy sidecar viene inserito in un pod di workload, le regole iptables vengono programmate in modo che il proxy acquisisca tutto il traffico TCP in entrata e in uscita. Tuttavia, come accennato in precedenza, esistono modi per i carichi di lavoro per aggirare il proxy. Le regole firewall VPC impediscono l'accesso in uscita diretto dai nodi predefiniti che eseguono i carichi di lavoro. Puoi utilizzare i criteri di rete Kubernetes per assicurarti che non sia possibile alcun traffico in uscita diretto esterno dagli spazi dei nomi dei carichi di lavoro e che sia possibile il traffico in uscita verso lo spazio dei nomi istio-egress.

Se controlli anche l'ingresso con i criteri di rete, devi creare criteri di ingresso corrispondenti a quelli di uscita.

Configurazione e sicurezza di Service Mesh

I carichi di lavoro in esecuzione in un mesh di servizi non vengono identificati in base ai relativi indirizzi IP. Cloud Service Mesh assegna un'identità sicura e verificabile sotto forma di un certificato e di una chiave X.509 per ogni carico di lavoro. La comunicazione attendibile tra i workload viene stabilita utilizzando connessioni TLS reciproca (mTLS) autenticate e criptate.

L'utilizzo dell'autenticazione mTLS con un'identità ben definita per ogni applicazione consente di utilizzare i criteri di autorizzazione del mesh per un controllo granulare su come i workload possono comunicare con i servizi esterni.

Sebbene il traffico possa uscire dal mesh direttamente dai proxy sidecar, se hai bisogno di un maggiore controllo, ti consigliamo di instradarlo tramite i gateway in uscita come descritto in questa guida.

Gestire la configurazione dei controlli in uscita in uno spazio dei nomi dedicato

Consenti agli amministratori di rete di gestire centralmente i controlli utilizzando un istio-egress spazio dei nomi dedicato per la configurazione del mesh relativa all'uscita. Come consigliato in precedenza, esegui il deployment del gateway in uscita nello spazio dei nomi istio-egress. Puoi creare e gestire voci di servizio, gateway e criteri di autorizzazione in questo spazio dei nomi.

Importante: per configurare il piano di controllo e i gateway del mesh, l'installatore di Cloud Service Mesh crea un ConfigMap Kubernetes nello spazio dei nomi istio-system. Se installi un gateway in un altro spazio dei nomi, devi copiare il ConfigMap in questo spazio dei nomi e gestire le impostazioni al suo interno durante l'upgrade. Una versione futura di Cloud Service Mesh gestirà automaticamente la configurazione del gateway.

Richiedere la configurazione esplicita delle destinazioni esterne

Assicurati che i proxy mesh siano programmati solo con route per host esterni che sono definiti esplicitamente nel registry del mesh di servizi. Imposta la modalità del criterio per il traffico in uscita su REGISTRY_ONLY in una risorsa sidecar predefinita per ogni spazio dei nomi. L'impostazione del criterio di traffico in uscita per il mesh non deve essere considerata, da sola, un controllo del perimetro sicuro.

Definire le destinazioni esterne con le voci di servizio

Configura Service Entries per registrare esplicitamente gli host esterni nel registry dei servizi del mesh. Per impostazione predefinita, le voci di servizio sono visibili a tutti gli spazi dei nomi. Utilizza l'attributo exportTo per controllare gli spazi dei nomi a cui è visibile una voce di servizio. Le voci di servizio determinano le route in uscita configurate nei proxy mesh, ma da sole non devono essere considerate un controllo sicuro per determinare a quali host esterni possono connettersi i carichi di lavoro.

Configura il comportamento del gateway in uscita con la risorsa Gateway

Configura il comportamento del bilanciamento del carico dei gateway in uscita utilizzando la risorsa Gateway. Il bilanciatore del carico può essere configurato per un determinato insieme di host, protocolli e porte e associato a un deployment di gateway in uscita. Ad esempio, un gateway potrebbe essere configurato per l'uscita alle porte 80 e 443 per qualsiasi host esterno.

In Cloud Service Mesh, l'automTLS è abilitata per impostazione predefinita. Con mTLS automatico, un proxy sidecar client rileva automaticamente se il server ha un sidecar. Il sidecar client invia mTLS ai workload con sidecar e invia traffico in testo normale ai workload senza sidecar. Anche con mTLS automatico, il traffico inviato al gateway in uscita dai proxy sidecar non utilizza automaticamente mTLS. Per indicare in che modo devono essere protette le connessioni al gateway di uscita, devi impostare la modalità TLS sulla risorsa Gateway. Se possibile, utilizza mTLS per le connessioni dai proxy sidecar al gateway di uscita.

È possibile consentire ai workload di avviare autonomamente le connessioni TLS (HTTPS). Se i carichi di lavoro originano connessioni TLS, in genere sulla porta 443, devi configurare il gateway in modo che utilizzi la modalità passthrough per le connessioni su quella porta. Tuttavia, l'utilizzo della modalità passthrough significa che il gateway non può applicare i criteri di autorizzazione in base all'identità del carico di lavoro o alle proprietà della richiesta criptata. Inoltre, al momento non è possibile utilizzare insieme mTLS e passthrough.

Configura i servizi virtuali e le regole di destinazione per instradare il traffico attraverso il gateway

Utilizza Servizi virtuali e Regole di destinazione per configurare l'instradamento del traffico dai proxy sidecar tramite il gateway di uscita alle destinazioni esterne. I servizi virtuali definiscono regole per l'associazione di determinate tipologie di traffico. Il traffico corrispondente viene quindi inviato a una destinazione. Le regole di destinazione possono definire sottoinsiemi (ad esempio il gateway di uscita o un host esterno) e come deve essere gestito il traffico durante l'inoltro alla destinazione.

Utilizza una singola regola di destinazione per più host di destinazione per specificare esplicitamente come deve essere protetto il traffico dai proxy sidecar al gateway. Come spiegato in precedenza, il metodo preferito è che i workload inviino richieste in testo normale e che il proxy sidecar origini una connessione mTLS al gateway.

Utilizza una regola di destinazione per ogni host esterno per configurare il gateway di uscita in modo da eseguire l'upgrade delle richieste HTTP semplici in modo da utilizzare una connessione TLS (HTTPS) durante l'inoltro alla destinazione. L'upgrade di una connessione in testo normale a TLS viene spesso definito originazione TLS.

Controllare l'ambito della configurazione del proxy con la risorsa Sidecar

Configura una risorsa sidecar predefinita per ogni spazio dei nomi per controllare il comportamento dei proxy sidecar. Utilizza la proprietà di uscita della risorsa Sidecar per controllare e ridurre al minimo gli host di destinazione configurati negli ascoltatori in uscita dei proxy. Una configurazione minima tipica potrebbe includere le seguenti destinazioni per ogni spazio dei nomi:

• Pod nello stesso spazio dei nomi
• API e servizi Google
• Il server di metadati GKE
• Host esterni specifici che sono stati configurati utilizzando le voci di servizio

La configurazione degli ascoltatori in uscita nei proxy sidecar non deve essere considerata da sola come controlli di sicurezza.

È consigliabile utilizzare le risorse Sidecar per limitare le dimensioni della configurazione del proxy. Per impostazione predefinita, ogni proxy sidecar in un mesh è configurato per consentire di inviare traffico a tutti gli altri proxy. Il consumo di memoria dei proxy sidecar e del piano di controllo può essere notevolmente ridotto limitando la configurazione dei proxy solo agli host con cui devono comunicare.

Utilizza il criterio di autorizzazione per consentire o negare il traffico al gateway in uscita

AuthorizationPolicy è una risorsa che consente di configurare un criterio di controllo dell'accesso granulare per il traffico della mesh. Puoi creare criteri per consentire o negare il traffico in base alle proprietà della sorgente, della destinazione o del traffico stesso (ad esempio l'host o le intestazioni di una richiesta HTTP).

Per consentire o negare le connessioni in base all'identità o al nome del workload di origine, la connessione al gateway di uscita deve essere autenticata con mTLS. Le connessioni dai sidecar al gateway di uscita non utilizzano automaticamente mTLS, pertanto la regola di destinazione per le connessioni al gateway deve specificare esplicitamente la modalità TLS ISTIO_MUTUAL.

Per consentire o negare le richieste al gateway utilizzando i criteri di autorizzazione, i workload devono inviare richieste HTTP semplici a destinazioni esterne al mesh. I proxy sidecar possono quindi inoltrare la richiesta al gateway utilizzando mTLS e il gateway può avviare una connessione TLS sicura all'host esterno.

Per supportare i requisiti di uscita di team e applicazioni diversi, configura criteri di autorizzazione "con privilegio minimo" separati per ogni spazio dei nomi o carico di lavoro. Ad esempio, è possibile applicare criteri diversi al gateway di uscita specificando regole in base allo spazio dei nomi del carico di lavoro di origine e agli attributi della richiesta come segue:

• Se lo spazio dei nomi di origine è team-x E l'host di destinazione è example.com, consenti il traffico.

  

• Se lo spazio dei nomi di origine è team-y E l'host di destinazione è httpbin.org E il percorso è /status/418, consenti il traffico.

  

Tutte le altre richieste vengono rifiutate.

Configura il gateway in uscita in modo che origini connessioni TLS (HTTPS) alla destinazione

Configura le regole di destinazione in modo che il gateway in uscita origini connessioni TLS (HTTPS) a destinazioni esterne.

Affinché l'originazione TLS nel gateway in uscita funzioni, i carichi di lavoro devono inviare richieste HTTP non protette. Se il workload avvia TLS, il gateway in uscita esegue il wrapping di TLS sopra il TLS originale e le richieste al servizio esterno non andranno a buon fine.

Poiché i workload inviano richieste HTTP semplici, configura il proxy sidecar del workload in modo da stabilire una connessione mTLS quando le invia al gateway. Il gateway in uscita termina quindi la connessione mTLS e avvia una normale connessione TLS (HTTPS) all'host di destinazione.

Questo approccio presenta diversi vantaggi:

• Puoi utilizzare un criterio di autorizzazione per consentire o negare il traffico in base agli attributi del workload di origine e delle richieste.

• Il traffico tra i pod di workload e il gateway in uscita è criptato e autenticato (mTLS) e il traffico tra il gateway in uscita e la destinazione è criptato (TLS/HTTPS).

• All'interno del mesh, i proxy sidecar possono osservare e intervenire sulle proprietà delle richieste HTTP (ad esempio le intestazioni), fornendo opzioni aggiuntive per l'osservabilità e il controllo.

• Il codice dell'applicazione può essere semplificato. Gli sviluppatori non devono gestire certificati o librerie client HTTPS e il mesh di servizi può garantire comunicazioni sicure con crittografia standard e aggiornata.

• Le connessioni TLS originate dal gateway in uscita ai servizi esterni possono essere riutilizzate per il traffico di molti pod. Il riutilizzo della connessione è più efficiente e riduce il rischio di raggiungere i limiti di connessione.

DNS, nomi host e caratteri jolly

Quando indirizzi, neghi o consenti il traffico in base all'host di destinazione, devi avere piena fiducia nell'integrità dei tuoi sistemi DNS per risolvere i nomi DNS nell'indirizzo IP corretto. Nei cluster Kubernetes Engine, il servizio DNS Kubernetes gestisce le query DNS e, a sua volta, delega le query esterne al server di metadati GKE e al DNS interno. Imposta l'attributo resolution delle voci di servizio su DNS quando esegui il routing verso host esterni, in modo che i proxy sidecar siano responsabili dell'esecuzione di query DNS.

Cloud Service Mesh può indirizzare il traffico in base agli host con caratteri jolly. Il caso più semplice è un carattere jolly per gli host che condividono un nome comune e sono ospitati su un insieme comune di server. Ad esempio, se un singolo insieme di server può gestire i domini corrispondenti a *.example.com, è possibile utilizzare un host jolly.

Un gateway in uscita standard non può inoltrare in base a host wildcard più generali e arbitrari (ad esempio *.com) a causa di alcune limitazioni del proxy Envoy utilizzato da Istio. Envoy può indirizzare il traffico solo ad host predefiniti, ad indirizzi IP predefiniti o all'indirizzo IP di destinazione originale di una richiesta. Quando utilizzi un gateway in uscita, l'IP di destinazione originale della richiesta viene perso perché viene sostituito dall'IP del gateway e gli host di destinazione arbitrari non possono essere preconfigurati.

Applicazione amministrativa delle norme

Utilizzare il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes

Solo gli amministratori autorizzati devono essere in grado di configurare i controlli in uscita. Configura il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes per evitare la circonvenzione non autorizzata dei controlli di uscita. Applica i ruoli RBAC in modo che solo gli amministratori di rete possano gestire gli spazi dei nomi istio-egress,istio-system, e kube-system e le seguenti risorse:

• Sidecar
• ServiceEntry
• Gateway
• AuthorizationPolicy
• NetworkPolicy

Limitare l'utilizzo delle tolleranze

Come descritto in precedenza, puoi utilizzare le incompatibilità e le tolleranze per impedire il deployment dei pod di carico di lavoro su nodi gateway. Tuttavia, per impostazione predefinita, non c'è nulla che impedisca il deployment dei carichi di lavoro con una tolleranza per i nodi gateway e, di conseguenza, consente di bypassare i controlli di uscita. Se è possibile applicare il controllo amministrativo centralizzato sulle pipeline di deployment, puoi utilizzarle per applicare limitazioni all'utilizzo di determinate chiavi di tolleranza.

Un altro approccio consiste nell'utilizzare il controllo dell'accesso di Kubernetes. Anthos include un componente chiamato Policy Controller che funge da controller di ammissione Kubernetes e convalida che i deployment soddisfino i vincoli dei criteri specificati.

Assicurati che il traffico venga registrato

Spesso è necessario registrare tutto il traffico che attraversa i perimetri di rete. Il logging del traffico è essenziale se devi dimostrare la conformità alle normative comuni sulla protezione dei dati. I log del traffico vengono inviati direttamente a Cloud Logging e è possibile accedervi dalle dashboard di Cloud Service Mesh nella console Google Cloud. Puoi filtrare i log in base a vari attributi, tra cui origine/destinazione, identità, spazio dei nomi, attributi del traffico e latenza.

Per consentire un facile debug con kubectl, abilita la registrazione del traffico in stdout durante l'installazione di Cloud Service Mesh utilizzando l'impostazione accessLogFile.

Gli audit log vengono inviati a Cloud Logging ogni volta che la CA Mesh crea un certificato per un carico di lavoro.

Valuta la possibilità di utilizzare un cluster separato per le gateway di uscita nei mesh multi-cluster

Cloud Service Mesh può essere implementato in più di un cluster GKE. Le mesh multicluster introducono nuove possibilità per controllare il traffico in uscita, ma anche alcune limitazioni.

Anziché eseguire il deployment del gateway di uscita in un pool di nodi dedicato, puoi eseguire il deployment del gateway in un cluster separato che non esegue carichi di lavoro regolari. L'utilizzo di un cluster distinto offre un isolamento simile tra carichi di lavoro e gateway, evitando al contempo la necessità di utilizzare contaminazioni e tolleranze. Il gateway in uscita può condividere il cluster separato con i gateway in entrata o altri servizi centrali.

Puoi utilizzare i criteri di rete Kubernetes nei deployment multi-cluster, ma poiché operano a livello 4 (trasporto), non possono limitare le connessioni tra cluster in base allo spazio dei nomi o al pod di destinazione.

Passaggi successivi

• Consulta la guida alla protezione di GKE
• Scopri come gestire la configurazione e i criteri in tutta l'infrastruttura con Anthos Configuration Management
• Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.