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

Questo documento descrive come utilizzare i gateway in uscita di Cloud Service Mesh e altri controlli Google Cloud per proteggere il traffico in uscita dai carichi di lavoro di 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.

Esiste un tutorial di accompagnamento che puoi utilizzare come modello per configurare i controlli di 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à alle normative (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. I firewall vengono utilizzati in questi perimetri per consentire o negare il traffico in base agli indirizzi IP di origine e di destinazione, mentre le applicazioni e il traffico contenuti all'interno del perimetro sono considerati attendibili. Tuttavia, questa fiducia comporta dei rischi. Un insider malintenzionato o chiunque comprometta il perimetro può muoversi liberamente all'interno della rete, accedere ed estrarre dati, attaccare sistemi di terze parti e interferire con i sistemi di amministrazione.

Quando i carichi di lavoro in esecuzione su un cluster Kubernetes stabiliscono connessioni in uscita agli host su internet, l'applicazione dei controlli di sicurezza tradizionali 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 effimero e vengono riciclati di frequente man mano che i pod vengono creati ed eliminati.

  • Spesso è impossibile identificare un insieme piccolo e fisso di indirizzi IP per host di destinazione specifici. Gli indirizzi IP cambiano spesso, variano in base alla regione e possono essere presi da intervalli di grandi dimensioni o rappresentare 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.

Cloud Service Mesh è un mesh di servizi completamente gestito su Google Cloud. Un mesh di servizi fornisce un modo uniforme per connettere, gestire e proteggere la comunicazione delle applicazioni. Le service mesh adottano un approccio incentrato sulle applicazioni e utilizzano identità delle 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 un controllo dichiarativo del comportamento della rete.

Cloud Service Mesh offre l'opzione di deployment di proxy di inoltro autonomi, noti come gateway in uscita, all'edge del mesh. Questa guida spiega come combinare le funzionalità del proxy del gateway di uscita con Google Cloud le funzionalità per controllare, autorizzare e osservare il traffico in uscita dai carichi di lavoro di cui è stato eseguito il deployment in un cluster GKE.

componenti concettuali

Architettura di difesa in profondità

Il seguente diagramma 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 sui controlli di rete di livello 4 (trasporto) che di livello 7 (applicazione).

architettura complessiva

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): Configura le regole firewall VPC per applicare i controlli di livello 4 (trasporto) alle connessioni da e verso i nodi nel cluster GKE. Puoi applicare le regole firewall VPC alle VM in base ai service account 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: crea spazi dei nomi per ogni team per fornire isolamento e controllo amministrativo delegato. Gli amministratori di rete utilizzano uno spazio dei nomi dedicato per implementare il gateway in uscita e configurare il routing agli host esterni.

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

  • Un gateway di uscita: il traffico che esce dai pod all'interno della mesh viene indirizzato tramite proxy gateway di uscita dedicati in esecuzione su nodi dedicati. Esegui il deployment dei gateway di uscita con un gestore della scalabilità automatica orizzontale dei pod 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 i controlli di livello 7 (applicazione) al traffico tra i pod all'interno del mesh e al traffico in uscita dal mesh.

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

  • Accesso Google privato: 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 per 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 la necessità di gestire i secret.

Configurazione dei controlli in uscita

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

Utilizzare GKE privato con Cloud NAT

Nei casi in cui la sicurezza è importante, il primo requisito di molte organizzazioni è quello di evitare di assegnare indirizzi IP pubblici ai propri carichi di lavoro. Un cluster GKE privato soddisfa questo requisito. Puoi configurare la modalità VPC nativo sul tuo cluster privato in modo che a pod e servizi vengano assegnati indirizzi IP da 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 carichi di lavoro di connettersi a host esterni senza che questi debbano avere indirizzi IP pubblici, configura Cloud NAT per fornire Network Address Translation (NAT).

Assicurati che Cloud NAT sia configurato in modo che il gateway di uscita possa stabilire un numero sufficiente di connessioni simultanee a destinazioni esterne. Puoi evitare l'esaurimento delle porte e i problemi con i ritardi nel riutilizzo delle connessioni impostando il numero minimo di porte per VM in modo appropriato. Per ulteriori dettagli, consulta la panoramica di indirizzi e porte Cloud NAT. L'aumento del numero di repliche del gateway di 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 accedere alle API e ai servizi di Google. Utilizza l'accesso privato Google con le zone DNS personalizzate per consentire la connettività dalle subnet VPC private alle API di Google utilizzando un insieme di quattro indirizzi IP. Quando utilizzi questi indirizzi IP, i pod non devono avere 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 tu utilizzi i controlli di servizio VPC.

Utilizzare Workload Identity e IAM per proteggere ulteriormente le API e i servizi Google

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

Quando utilizzi l'accesso privato Google, Workload Identity e IAM, puoi consentire in modo sicuro ai pod dei carichi 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 la responsabilità amministrativa per gruppi di risorse Kubernetes a diversi amministratori.

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.

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 mesh e le risorse sidecar possono limitare la visibilità e l'accesso in base allo spazio dei nomi, all'identità e agli attributi di livello 7 (applicazione) del traffico di rete.

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

Esegui gateway in uscita su nodi gateway dedicati

L'esecuzione di gateway di uscita sui nodi in un pool di nodi gateway dedicato offre diversi vantaggi. I nodi rivolti verso l'esterno possono utilizzare una configurazione rafforzata e puoi configurare le regole 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 dei cluster.

Per consentire il controllo amministrativo separato del gateway di 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 di 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. Gli altri pod devono essere respinti dai nodi gateway, altrimenti i controlli di uscita potrebbero essere bypassati. L'esecuzione dei carichi di lavoro su determinati nodi può essere impedita utilizzando incompatibilità e tolleranze. Devi contrassegnare i nodi nel pool di nodi del gateway e aggiungere una tolleranza corrispondente al deployment del gateway di uscita.

Applicare regole firewall VPC a nodi specifici

Configura il routing mesh di servizi per indirizzare il traffico in uscita dai carichi di lavoro in esecuzione nelpool di nodil predefinito tramite i gateway in uscita in esecuzione nepool di nodiol del gateway. Tuttavia, la configurazione di routing del mesh non deve essere considerata un limite di sicurezza perché esistono vari modi in cui un workload potrebbe bypassare i proxy mesh.

Per impedire ai carichi di lavoro delle applicazioni di connettersi direttamente agli host esterni, applica regole firewall in uscita restrittive ai nodi nelpool di nodil predefinito. Applica regole firewall separate ai nodi gateway in modo che i pod gateway di uscita in esecuzione su questi nodi 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 si applica. Le regole di uscita si applicano al traffico in uscita e le regole di entrata si applicano al traffico in entrata. Il valore predefinito per il traffico in uscita è allow e quello 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 un traffico specifico da una VM è consentito, anche il traffico di ritorno che utilizza la stessa connessione è consentito.

Il seguente diagramma mostra come è possibile 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 ignorare 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 a host esterni sulle porte 80 e 443. Il pool di nodi predefinito non ha accesso agli host esterni.

pool di nodi firewall

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 sono limitati agli spazi dei nomi e operano a 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 porte e blocchi IP particolari.

Dopo che un criterio di rete seleziona i pod in uno spazio dei nomi, tutte le connessioni non consentite in modo esplicito vengono rifiutate. Quando vengono applicate più norme relative alla rete, il risultato è additivo e rappresenta l'unione delle norme. L'ordine in cui vengono applicate le norme non è importante.

Il tutorial di accompagnamento 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-system e istio-egress. I pod devono essere in grado di connettersi a control-plane e al gateway di 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.
  • (Facoltativo) 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 team di applicazioni diversi.
  • Consenti le connessioni in uscita dagli spazi dei nomi dei workload 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, quindi i proxy sidecar devono essere in grado di connettersi. È anche probabile che alcuni carichi di lavoro debbano accedere alle API di Google.
  • Consenti le connessioni in uscita dagli spazi dei nomi dei workload al server di metadati GKE in modo che i proxy sidecar e i workload possano eseguire query sui metadati ed eseguire l'autenticazione alle API di Google.

Per impostazione predefinita, quando un proxy sidecar viene inserito in un pod del workload, vengono programmate regole iptables 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 di bypassare il proxy. Le regole firewall VPC impediscono l'accesso diretto in uscita 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 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 l'ingresso con le policy di rete, devi creare policy di ingresso che corrispondano alle policy di uscita.

Configurazione e sicurezza del service mesh

I carichi di lavoro in esecuzione in un mesh di servizi non vengono identificati in base ai loro indirizzi IP. Cloud Service Mesh assegna un'identità sicura e verificabile sotto forma di certificato e 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 ti 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 dalla mesh direttamente dai proxy sidecar, se hai bisogno di un controllo aggiuntivo, ti consigliamo di instradare il traffico attraverso i gateway di uscita come descritto in questa guida.

Gestisci la configurazione per i controlli di uscita in uno spazio dei nomi dedicato

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

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 exportTo per controllare a quali spazi dei nomi è visibile una voce di servizio. Le voci di servizio determinano le route in uscita configurate nei proxy mesh, ma non devono essere considerate di per sé un controllo sicuro per determinare a quali host esterni possono connettersi i workload.

Configurare 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 a un deployment del gateway di uscita. Ad esempio, un gateway potrebbe essere configurato per l'uscita verso le porte 80 e 443 per qualsiasi host esterno.

Cloud Service Mesh abilita mTLS automatico per impostazione predefinita. Con mTLS automatico, un proxy sidecarr lato client rileva automaticamente se il server ha un sidecar. Il sidecar lato client invia mTLS ai workload con sidecar e traffico di testo normale ai workload senza sidecar. Anche con mTLS automatico, il traffico inviato al gateway di uscita dai proxy sidecar non utilizza automaticamente mTLS. Per indicare come devono essere protette le connessioni al gateway di uscita, devi impostare la modalità TLS nella risorsa Gateway. Se possibile, utilizza mTLS per le connessioni dai proxy sidecar al gateway di uscita.

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

Utilizza Virtual Services e Destination Rules per configurare il routing del traffico dai proxy sidecar tramite il gateway di uscita verso destinazioni esterne. I servizi virtuali definiscono regole per la corrispondenza di un determinato 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 quando viene indirizzato alla destinazione.

Utilizza una singola regola di destinazione per più host di destinazione per specificare in modo esplicito come proteggere il traffico dai proxy sidecar al gateway. Come spiegato in precedenza, il metodo preferito prevede che i workload inviino richieste in testo normale e che il proxy sidecar crei una connessione mTLS al gateway.

Utilizza una regola di destinazione per ogni host esterno per configurare il gateway di uscita in modo da "aggiornare" le richieste HTTP semplici in modo che utilizzino una connessione TLS (HTTPS) quando vengono inoltrate alla destinazione. L'upgrade di una connessione di testo normale a TLS viene spesso definito originazione TLS.

Utilizza Authorization Policy per consentire o negare il traffico nel gateway di uscita

AuthorizationPolicy è una risorsa che consente di configurare criteri 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 allo spazio dei nomi 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, quindi 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 le norme di autorizzazione, i workload devono inviare richieste HTTP semplici alle destinazioni al di fuori del mesh. I proxy sidecar possono quindi inoltrare la richiesta al gateway utilizzando mTLS e il gateway può stabilire 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 spazio dei nomi o carico di lavoro. Ad esempio, è possibile applicare criteri diversi al gateway di uscita specificando regole basate sullo spazio dei nomi del carico di lavoro di origine e sugli attributi della richiesta nel seguente modo:

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

    esempio di criteri di autorizzazione

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

    criteri di autorizzazione utilizzando httpbin

Tutte le altre richieste vengono rifiutate.

Configura il gateway di uscita per generare connessioni TLS (HTTPS) alla destinazione

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

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

Poiché i workload inviano richieste HTTP semplici, configura il proxy sidecarr del workload per stabilire una connessione mTLS quando le invii al gateway. Il gateway di uscita termina quindi la connessione mTLS e genera una normale connessione TLS (HTTPS) all'host di destinazione.

Originazione TLS nel gateway in uscita

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 del workload e il gateway di uscita è criptato e autenticato (mTLS), mentre il traffico tra il gateway di uscita e la destinazione è criptato (TLS/HTTPS).

  • All'interno del mesh, i proxy sidecar possono osservare e agire in base alle 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 ilmesh di servizih può garantire una comunicazione sicura con cifrari standard e aggiornati.

  • Le connessioni TLS originate dal gateway di uscita ai servizi esterni possono essere riutilizzate per il traffico proveniente da 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 esegui il routing, 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 durante il routing agli host esterni, in modo che i proxy sidecar siano responsabili dell'esecuzione delle query DNS.

Cloud Service Mesh può instradare il traffico in base agli host 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 di uscita standard non può inoltrare in base a host jolly più generali e arbitrari (ad esempio *.com) a causa di alcune limitazioni del proxy Envoy utilizzato da Istio. Envoy può instradare il traffico solo verso host predefiniti, indirizzi IP predefiniti o verso l'indirizzo IP di destinazione originale di una richiesta. Quando utilizzi un gateway di uscita, l'IP di destinazione originale della richiesta viene perso perché viene sostituito con l'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 di uscita. Configura il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per evitare l'elusione 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, ekube-system e le seguenti risorse:

  • Sidecar
  • ServiceEntry
  • Gateway
  • AuthorizationPolicy
  • NetworkPolicy

Limitazione dell'utilizzo delle tolleranze

Come descritto in precedenza, puoi utilizzare incompatibilità e tolleranze per impedire il deployment dei pod del workload 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 e quindi consenta di bypassare i controlli di uscita. Se è possibile applicare un controllo amministrativo centralizzato sulle pipeline di deployment, puoi utilizzarle per applicare restrizioni all'utilizzo di determinate chiavi di tolleranza.

Un altro approccio consiste nell'utilizzare il controllo di ammissione di Kubernetes. Anthos include un componente chiamato Policy Controller che funge da controller di ammissione Kubernetes e verifica 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. La registrazione del traffico è essenziale se devi essere in grado di dimostrare la conformità ai regolamenti comuni in materia di protezione dei dati. I log del traffico vengono inviati direttamente a Cloud Logging e possono essere accessibili 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 il debug semplice con kubectl, attiva 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 Mesh CA crea un certificato per un workload.

Valuta la possibilità di utilizzare un cluster separato per i gateway di uscita nelle mesh multicluster

Cloud Service Mesh può essere distribuito su più di un cluster GKE. Le mesh multicluster introducono nuove possibilità per controllare il traffico in uscita e 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 workload regolari. L'utilizzo di un cluster separato fornisce un isolamento simile tra carichi di lavoro e gateway, evitando la necessità di taint e tolleranze. Il gateway di uscita può condividere il cluster separato con i gateway di ingresso o altri servizi centrali.

Puoi utilizzare i criteri di rete Kubernetes nei deployment multicluster, 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