Questo documento descrive come utilizzare i gateway in uscita di Anthos Service Mesh e altri controlli di Google Cloud per proteggere il traffico in uscita dai carichi di lavoro di cui è stato eseguito il deployment su un cluster Google Kubernetes Engine (GKE). Questi controlli possono limitare le connessioni a 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.
È disponibile un tutorial companion che puoi utilizzare come progetto per configurare i controlli in uscita nei tuoi cluster.
Il pubblico di destinazione di questo documento include ingegneri di rete, piattaforma e 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à ai regolamenti, ad esempio GDPR e PCI.
Introduzione
L'approccio tradizionale alla sicurezza di rete consiste nel definire perimetri di sicurezza intorno a un gruppo di applicazioni. In questi perimetri vengono utilizzati firewall 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 contenuto all'interno del perimetro. Tuttavia, questa fiducia comporta dei rischi. Un utente malintenzionato interno al perimetro o chiunque comprometta il perimetro può spostarsi liberamente all'interno della rete, accedere ai dati ed esfiltrarli, 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 verso host su internet, l'applicazione dei tradizionali controlli di sicurezza basati su IP può essere complicata perché:
Gli indirizzi IP dei pod non rappresentano in modo adeguato l'identità del carico di lavoro che effettua la connessione. In un ambiente Kubernetes, gli indirizzi IP dei pod vengono assegnati in modo temporaneo e vengono riciclati frequentemente all'uscita dei pod.
Spesso è impossibile identificare un insieme piccolo e fisso di indirizzi IP per determinati host di destinazione. Gli indirizzi IP cambiano di frequente, variano in base all'area geografica e possono essere acquisiti da intervalli di grandi dimensioni o rappresentano cache, proxy o CDN.
Più team che condividono lo stesso cluster multi-tenant, con un intervallo condiviso di IP di origine, potrebbero avere requisiti di connettività esterna diversi.
Anthos Service Mesh è la distribuzione completamente supportata da Google del mesh di servizi open source Istio. Un mesh di servizi fornisce un modo uniforme per connettere, gestire e proteggere le comunicazioni delle applicazioni. I mesh di servizi adottano un approccio incentrato sulle applicazioni e utilizzano identità di applicazioni attendibili anziché un approccio incentrato sull'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 responsabili della distribuzione e del rilascio delle funzionalità delle applicazioni dalle responsabilità degli amministratori di rete fornendo il controllo dichiarativo del comportamento della rete.
Anthos Service Mesh offre l'opzione per eseguire il deployment di proxy di forwarding autonomi, noti come gateway in uscita, sul perimetro del mesh. Questa guida spiega in che modo 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à al controllo granulare del traffico in uscita per un cluster utilizzato da più team. I controlli sono basati sui controlli di rete del livello 4 (trasporto) e del livello 7 (applicazione).
L'architettura utilizza le risorse e i controlli seguenti:
Un cluster GKE privato: i nodi su 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 VPC (Virtual Private Cloud): configuri le regole firewall VPC per applicare i controlli di livello 4 (trasporto) alle connessioni da e verso i nodi nel 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: in questo modo puoi configurare regole firewall diverse da applicare a seconda del pool di nodi a cui appartiene un nodo.
Spazi dei nomi Kubernetes: puoi creare spazi dei nomi per ogni team al fine di fornire l'isolamento e il controllo amministrativo delegato. Gli amministratori di rete utilizzano uno spazio dei nomi dedicato per eseguire il deployment del gateway in uscita e per configurare il routing su host esterni.
Criteri di rete di Kubernetes: i criteri di rete consentono di applicare controlli di livello 4 ai pod. Ogni criterio di rete ha uno spazio dei nomi e può limitare in modo più preciso l'ambito a pod specifici in uno spazio dei nomi.
Un gateway in uscita: il traffico in uscita dai pod all'interno del mesh è diretto attraverso proxy del gateway in uscita dedicati in esecuzione su nodi dedicati. Puoi eseguire il deployment dei gateway in uscita con un gestore della scalabilità automatica pod orizzontale in modo che il numero di repliche faccia lo scale up e lo scale down con il traffico.
Criteri di autorizzazione: utilizzi i criteri di autorizzazione della rete mesh per applicare i controlli di livello 7 (applicazione) al traffico tra i pod all'interno del mesh e al traffico in uscita dal mesh.
Risorse Sidecar: puoi utilizzare le risorse Sidecar per controllare l'ambito di configurazione dei proxy sidecar in esecuzione in ciascun pod del carico di lavoro. Puoi utilizzare la risorsa Sidecar per configurare gli spazi dei nomi, i pod e i servizi esterni visibili a un carico di lavoro.
Accesso privato Google: questa opzione consente a nodi e pod nel cluster privato di accedere alle API di Google e di estrarre immagini Docker da Container Registry.
GKE Workload Identity: 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 la necessità di gestire secret.
Configurazione dei controlli del traffico in uscita
Se utilizzi il gateway in uscita per proteggere il traffico in uscita dalla rete mesh, ti consigliamo di configurare i controlli per la difesa in profondità descritti in questa sezione.
Utilizzo di GKE privato con Cloud NAT
Laddove la sicurezza sia importante, il primo requisito di molte organizzazioni è evitare di assegnare indirizzi IP pubblici ai propri carichi di lavoro. Un cluster GKE privato soddisfa questo requisito. Puoi configurare la modalità native VPC sul cluster privato in modo che a pod e servizi vengano assegnati indirizzi IP da intervalli secondari nel VPC. Gli indirizzi IP dei pod nativi VPC sono instradabili in modo nativo all'interno della rete VPC.
Alcuni carichi di lavoro potrebbero richiedere l'accesso a servizi al di fuori della rete VPC e a internet. Per consentire ai carichi di lavoro di connettersi a host esterni senza che abbiano indirizzi IP pubblici, configura Cloud NAT in modo che fornisca il servizio Network Address Translation (NAT).
Assicurati che Cloud NAT sia configurato in modo che il gateway in uscita possa effettuare un numero sufficiente di connessioni simultanee verso destinazioni esterne. Puoi evitare l'esaurimento delle porte e problemi relativi ai ritardi per il riutilizzo della connessione impostando in modo appropriato il numero minimo di porte per VM. Per ulteriori dettagli, consulta la panoramica degli indirizzi e delle porte di Cloud NAT. L'aumento del numero di repliche del gateway in uscita può contribuire a ridurre le probabilità di conflitti di mappatura indipendenti dall'endpoint.
Configurare l'accesso privato Google per API e servizi Google
È probabile che i carichi di lavoro debbano avere accesso alle API e ai servizi Google. Utilizza l'accesso privato Google con
zone DNS personalizzate
per consentire la connettività da subnet VPC private alle API di Google utilizzando un insieme di
quattro indirizzi IP. Quando si utilizzano questi indirizzi IP, non è necessario che i pod abbiano indirizzi IP esterni e il traffico non esce mai dalla rete Google. Puoi
utilizzare private.googleapis.com (199.36.153.8/30) o
restricted.googleapis.com (199.36.153.4/30), a seconda che utilizzi
Controlli di servizio VPC.
Utilizza Workload Identity e IAM per proteggere ulteriormente le API e i servizi Google
L'utilizzo di Workload Identity è il modo consigliato per consentire ai carichi di lavoro GKE di eseguire l'autenticazione con le API di Google e per gli amministratori di applicare controlli di autorizzazione con "privilegio minimo" utilizzando IAM.
Quando utilizzi l'accesso privato Google, Workload Identity e IAM, puoi consentire in sicurezza ai pod dei carichi di lavoro di bypassare il gateway in uscita e di 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 in cui esistono molti utenti, team o tenant. Possono essere considerati come un cluster virtuale e consentono la responsabilità amministrativa di gruppi di risorse Kubernetes di essere delegati ad amministratori diversi.
Gli spazi dei nomi sono una funzionalità importante per l'isolamento del controllo amministrativo. Tuttavia, per impostazione predefinita, non forniscono isolamento dei nodi, del piano dati o della rete.
Anthos 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 collaterali 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.
Allo stesso modo, puoi utilizzare i criteri di rete di Kubernetes per consentire o negare le connessioni di rete al livello 4 (trasporto).
Esegui gateway in uscita su nodi gateway dedicati
L'esecuzione di gateway in uscita sui nodi in un pool di nodi gateway dedicato offre diversi vantaggi. I nodi rivolti all'esterno possono utilizzare una configurazione protetta e puoi configurare le regole firewall VPC per impedire ai carichi di lavoro di raggiungere direttamente gli host esterni. I pool di nodi possono essere scalati automaticamente in modo indipendente utilizzando il gestore della scalabilità automatica dei 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 membri del pool di nodi del gateway.
Assicurati che solo i pod gateway possano essere eseguiti sui nodi gateway. Altri pod dovrebbero essere respinti dai nodi gateway, altrimenti i controlli in uscita potrebbero essere ignorati. È possibile impedire l'esecuzione dei carichi di lavoro su determinati nodi utilizzando incompatibilità e tolleranze. Devi incompatibilità dei nodi nel pool di nodi del gateway e aggiungere una tolleranza corrispondente al deployment del gateway in uscita.
Applica le regole firewall VPC a nodi specifici
Puoi configurare il routing del mesh di servizi in modo da indirizzare il traffico in uscita dai carichi di lavoro in esecuzione nel pool di nodi predefinito attraverso i gateway in uscita in esecuzione nel pool di nodi del gateway. Tuttavia, la configurazione di routing del mesh non deve essere considerata un confine di sicurezza perché esistono vari modi in cui un carico di lavoro potrebbe bypassare i proxy mesh.
Per impedire ai carichi di lavoro delle applicazioni di connettersi direttamente a host esterni, applica regole firewall in uscita restrittive ai nodi nel pool di nodi predefinito. Applica regole firewall separate ai nodi gateway in modo che i pod del gateway in uscita in esecuzione su di essi possano connettersi a host esterni.
Quando crei una regola firewall VPC, specifichi le porte e i protocolli che la regola firewall consente o nega e la direzione del traffico a cui viene applicata. Le regole in uscita si applicano al traffico in uscita, mentre
le regole in entrata si applicano al traffico in entrata. Il valore predefinito per il traffico in entrata è allow,
mentre per il traffico in entrata è deny.
Le regole firewall vengono applicate in ordine in base a un numero di priorità che puoi specificare. Le regole firewall sono stateful, il che significa che, se è consentito il traffico specifico da una VM, è consentito anche il traffico di ritorno utilizzando la stessa connessione.
Il seguente diagramma mostra come applicare regole firewall separate ai nodi in due diversi pool di nodi 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'intero VPC. Per evitare di eseguire l'override delle 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 con priorità più alta per consentire la connessione diretta a host esterni sulle porte 80 e 443. Il pool di nodi predefinito non ha accesso agli host esterni.
Usare i criteri di rete di Kubernetes come firewall per pod e spazi dei nomi
Utilizza i criteri di rete di Kubernetes per applicare un ulteriore livello di sicurezza come parte di una strategia di difesa in profondità. I criteri di rete hanno come ambito gli spazi dei nomi e operano al livello 4 (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 determinate porte e blocchi IP.
Dopo che un criterio di rete seleziona i pod in uno spazio dei nomi, tutte le connessioni che non sono consentite esplicitamente vengono rifiutate. Quando vengono applicati più criteri di rete, il risultato è cumulativo ed è l'unione dei criteri. L'ordine in cui vengono applicati i criteri non è importante.
Il tutorial companion include i seguenti esempi di criteri di rete:
- Consenti le connessioni in uscita dagli spazi dei nomi dei carichi di lavoro agli spazi dei nomi
istio-systemeistio-egress. I pod devono potersi connettere a istiod 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 delle applicazioni.
- Consenti le connessioni in uscita dagli spazi dei nomi dei carichi di lavoro ai VIP per le API di Google (esposte utilizzando l'accesso privato Google). Anthos Service Mesh fornisce una CA gestita e la espone come API, per cui i proxy sidecar devono potersi connettere a questa CA. È anche probabile che alcuni carichi di lavoro debbano accedere alle API di Google.
- Consenti 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 ed eseguire l'autenticazione nelle API di Google.
Per impostazione predefinita, quando un proxy sidecar viene inserito in un pod del carico di lavoro, 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, i carichi di lavoro possono aggirare il proxy. Le regole firewall VPC impediscono l'accesso diretto al traffico in uscita dai nodi predefiniti che eseguono i carichi di lavoro. Puoi utilizzare i criteri di rete di Kubernetes per assicurarti che non sia possibile alcun traffico esterno diretto dagli spazi dei nomi dei carichi di lavoro e che il traffico in uscita sia possibile verso lo spazio dei nomi istio-egress.
Se controlli anche il traffico in entrata con i criteri di rete, devi creare criteri in entrata in modo che corrispondano a quelli in uscita.
Configurazione e sicurezza di Anthos Service Mesh
I carichi di lavoro in esecuzione in un mesh di servizi non vengono identificati in base ai relativi indirizzi IP. Anthos Service Mesh assegna un'identità solida e verificabile sotto forma di certificato e chiave X.509 per ogni carico di lavoro. La comunicazione attendibile tra i carichi di lavoro viene stabilita utilizzando connessioni mTLS (mutual TLS) autenticate e criptate.
L'uso dell'autenticazione mTLS con un'identità ben definita per ogni applicazione consente di utilizzare i criteri di autorizzazione mesh per un controllo granulare su come i carichi di lavoro possono comunicare con i servizi esterni.
Anche se il traffico può uscire dal mesh direttamente dai proxy sidecar, se hai bisogno di un controllo aggiuntivo ti consigliamo di instradare il traffico attraverso gateway in uscita come descritto in questa guida.
Gestisci la configurazione per i controlli in uscita in uno spazio dei nomi dedicato
Consenti agli amministratori di rete di gestire centralmente i controlli utilizzando uno spazio dei nomi istio-egress dedicato per la configurazione del mesh relativa al traffico in 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.
Richiedere la configurazione esplicita delle destinazioni esterne
Assicurati che i proxy mesh siano programmati solo con route verso host esterni definiti esplicitamente nel registro del mesh di servizi. Imposta la modalità dei criteri del traffico in uscita su REGISTRY_ONLY in una risorsa collaterale predefinita per ogni spazio dei nomi. L'impostazione dei criteri per il traffico in uscita per il mesh non deve essere considerata da sola un controllo del perimetro sicuro.
Definisci le destinazioni esterne con le voci di servizio
Configura le Voci di servizio per registrare esplicitamente gli host esterni nel registro dei servizi del mesh. Per impostazione predefinita, le voci di servizio sono visibili a tutti gli spazi dei nomi. Utilizza l'attributo esportazioneTo per controllare gli spazi dei nomi per i quali è visibile una voce di servizio. Le voci di servizio determinano le route in uscita configurate nei proxy mesh, ma non devono, da solo, essere considerate un controllo sicuro per determinare a quali carichi di lavoro host esterni possono connettersi.
Configura il comportamento del gateway in uscita con la risorsa Gateway
Configura il comportamento di 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 al deployment di un gateway in uscita. Ad esempio, un gateway potrebbe essere configurato per il traffico in uscita verso le porte 80 e 443 per qualsiasi host esterno.
In Anthos Service Mesh 1.6 e versioni successive, mTLS automatico è abilitato per impostazione predefinita. Con mTLS automatico, un proxy sidecar client rileva automaticamente se il server ha un file collaterale. Il client collaterale invia mTLS ai carichi di lavoro con sidecar e invia traffico di testo normale ai carichi di lavoro senza sidecar. Anche con mTLS automatico, il traffico inviato al gateway in uscita dai proxy sidecar non utilizza automaticamente mTLS. Per indicare come devono essere protette le connessioni al gateway in uscita, devi impostare la modalità TLS nella risorsa Gateway. Se possibile, utilizza mTLS per le connessioni dai proxy sidecar al gateway in uscita.
È possibile consentire ai carichi di lavoro di avviare connessioni TLS (HTTPS). Se i carichi di lavoro provengono da 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 criteri di autorizzazione in base all'identità del carico di lavoro o alle proprietà della richiesta criptata. Inoltre, al momento non è possibile utilizzare
mTLS e passthrough insieme.
Configura i servizi virtuali e le regole di destinazione per instradare il traffico attraverso il gateway
Utilizza i servizi virtuali e le regole di destinazione per configurare il routing del traffico dai proxy sidecar attraverso il gateway in uscita verso destinazioni esterne. I servizi virtuali definiscono le regole per la corrispondenza di un determinato traffico. Il traffico con corrispondenze viene quindi inviato a una destinazione. Le regole di destinazione possono definire sottoinsiemi (ad esempio, il gateway in uscita o un host esterno) e la modalità di gestione del traffico quando viene instradato alla destinazione.
Utilizza un'unica regola di destinazione per più host di destinazione per specificare esplicitamente in che modo deve essere protetto il traffico dai proxy sidecar al gateway. Come spiegato in precedenza, il metodo preferito prevede l'invio di richieste di testo normale da parte dei carichi di lavoro e l'invio da parte del proxy sidecar di una connessione mTLS al gateway.
Utilizza una regola di destinazione per ciascun host esterno per configurare il gateway in 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 è spesso indicato come originazione TLS.
Controlla l'ambito della configurazione del proxy con la risorsa Sidecar
Configura una risorsa Sidecar predefinita per ogni spazio dei nomi al fine di controllare il comportamento dei proxy sidecar. Utilizza la proprietà in uscita della risorsa Sidecar per controllare e ridurre al minimo gli host di destinazione configurati nei listener in uscita dei proxy. Una tipica configurazione minima 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 configurati utilizzando voci di servizio
La configurazione dei listener in uscita nei proxy sidecar non dovrebbe, da sola, essere considerata come controlli di sicurezza.
Una best practice consiste nell'utilizzare risorse Sidecar per limitare le dimensioni della configurazione del proxy. Per impostazione predefinita, ogni proxy sidecar in un mesh è configurato in modo da consentire l'invio del traffico a ogni altro 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 criteri di controllo granulare degli accessi per il traffico mesh. Puoi creare criteri per consentire o negare il traffico in base alle proprietà dell'origine, della destinazione o al traffico stesso (ad esempio, l'host o le intestazioni di una richiesta HTTP).
Per consentire o negare le connessioni in base all'identità o allo spazio dei nomi del carico di lavoro di origine, la connessione al gateway in uscita deve essere autenticata con mTLS. Le connessioni dai file collaterali al gateway in 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 carichi di lavoro 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ò generare una connessione TLS sicura all'host esterno.
Per supportare i requisiti in uscita di team e applicazioni diversi, configura criteri di autorizzazione "privilegio minimo" separati per spazio dei nomi o carico di lavoro. Ad esempio, possono essere applicati diversi criteri al gateway in uscita specificando regole basate sullo spazio dei nomi del carico di lavoro di origine e sugli 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 per generare connessioni TLS (HTTPS) verso la destinazione
Configura le regole di destinazione in modo che il gateway in uscita invii connessioni TLS (HTTPS) verso destinazioni esterne.
Affinché l'originazione TLS nel gateway in uscita funzioni, i carichi di lavoro devono inviare richieste HTTP semplici. Se il carico di lavoro avvia TLS, il gateway in uscita esegue il wrapping di TLS sulla crittografia originale e le richieste al servizio esterno avranno esito negativo.
Poiché i carichi di lavoro inviano richieste HTTP semplici, configura il proxy sidecar del carico di lavoro in modo da stabilire una connessione mTLS quando li invii al gateway. Il gateway in uscita termina quindi la connessione mTLS e ha origine da 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 carico di lavoro di origine e alle richieste.
Il traffico tra i pod dei carichi di lavoro 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 agire sulle proprietà delle richieste HTTP (ad esempio le intestazioni), fornendo ulteriori opzioni per l'osservabilità e il controllo.
Il codice dell'applicazione può essere semplificato. Non è necessario che gli sviluppatori abbiano a che fare con certificati o librerie client HTTPS e il mesh di servizi può garantire comunicazioni sicure con crittografie standard e aggiornate.
Le connessioni TLS che il gateway in uscita ha origine verso servizi esterni possono essere riutilizzate per il traffico da molti pod. Il riutilizzo delle connessioni è più efficiente e riduce il rischio di raggiungimento dei limiti di connessioni.
DNS, nomi host e caratteri jolly
Quando esegui il routing, il rifiuto o l'autorizzazione del traffico in base all'host di destinazione, devi fidarti completamente dell'integrità dei tuoi sistemi DNS per risolvere i nomi DNS nell'indirizzo IP corretto. Sui cluster Kubernetes Engine, il servizio DNS di 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 di risoluzione delle voci di servizio su DNS per il routing a host esterni, in modo che i proxy sidecar siano responsabili dell'esecuzione delle query DNS.
Anthos Service Mesh può indirizzare il traffico in base a 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 in base a *.example.com, è possibile utilizzare un host con caratteri jolly.
Un gateway in uscita standard non può eseguire l'inoltro in base a host con caratteri jolly più generici e arbitrari (ad esempio *.com) a causa di alcune limitazioni del proxy Envoy utilizzato da Istio. Envoy può indirizzare il traffico solo a host predefiniti, 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 va perso perché viene sostituito con l'IP del gateway e gli host di destinazione arbitrari non possono essere preconfigurati.
Applicazione amministrativa dei criteri
Usa il controllo dell'accesso basato su ruoli (RBAC) di Kubernetes
Solo gli amministratori autorizzati devono essere in grado di configurare i controlli in uscita.
Configura il controllo dell'accesso basato sui ruoli di Kubernetes (RBAC) per evitare l'elusione non autorizzata dei controlli in uscita. Applica i ruoli RBAC in modo che solo gli amministratori di rete possano gestire gli spazi dei nomi istio-egress,istio-system,ekube-system e le seguenti risorse:
- Sidecar
- ServiceEntry
- Gateway
- AuthorizationPolicy
- NetworkPolicy
Limitazione dell'uso delle tolleranze
Come descritto in precedenza, puoi utilizzare incompatibilità e tolleranze per impedire il deployment dei pod dei carichi di lavoro sui nodi gateway. Tuttavia, per impostazione predefinita, non esiste nulla che impedisca il deployment dei carichi di lavoro con una tolleranza per i nodi gateway, consentendo quindi di bypassare i controlli in uscita. Se è possibile applicare il controllo amministrativo centralizzato sulle pipeline di deployment, puoi utilizzarle per applicare restrizioni all'uso di determinate chiavi di tolleranza.
Un altro approccio è utilizzare il controllo di ammissione di Kubernetes. Anthos include un componente chiamato Policy Controller che agisce da controller di ammissione Kubernetes e verifica che i deployment soddisfino i vincoli dei criteri da te specificati.
Assicurati che il traffico sia registrato
Spesso è necessario registrare tutto il traffico che attraversa i perimetri di rete. Il logging del traffico è essenziale se devi essere in grado di dimostrare la conformità alle normative comuni sulla protezione dei dati. I log sul traffico vengono inviati direttamente a Cloud Logging e sono accessibili dalle dashboard di Anthos 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 il logging del traffico in stdout quando installi Anthos Service Mesh utilizzando l'impostazione accessLogFile.
Gli audit log vengono inviati a Cloud Logging ogni volta che Mesh CA crea un certificato per un carico di lavoro.
Valuta l'utilizzo di un cluster separato per i gateway in uscita in mesh multi-cluster
È possibile eseguire il deployment di Anthos Service Mesh in più cluster GKE. I mesh multi-cluster offrono nuove possibilità per controllare il traffico in uscita oltre ad alcune limitazioni.
Anziché eseguire il deployment del gateway in uscita in un pool di nodi dedicato, puoi eseguirne il deployment in un cluster separato che non esegue carichi di lavoro normali. L'utilizzo di un cluster separato fornisce un isolamento simile tra carichi di lavoro e gateway, evitando al contempo la necessità di incompatibilità e tolleranze. Il gateway in uscita può condividere il cluster separato con gateway in entrata o altri servizi centrali.
Puoi utilizzare i criteri di rete di Kubernetes in deployment multi-cluster, ma poiché operano al livello 4 (trasporto), non possono limitare le connessioni tra cluster in base allo spazio dei nomi o al pod di destinazione.
Passaggi successivi
- Prova il tutorial sui companion
- Consulta la guida alla protezione di GKE
- Scopri come gestire configurazione e criteri nell'intera infrastruttura con Anthos Configuration Management
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.