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

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

C'è un tutorial sugli annunci companion che puoi utilizzare come modello per configurare i controlli in uscita cluster.

I destinatari di questo documento includono rete, piattaforma e tecnici della sicurezza che amministrano i cluster GKE utilizzati da uno team di distribuzione del software. I controlli descritti qui potrebbero essere particolarmente utile per le organizzazioni che devono dimostrare conformità normative (ad es. GDPR) e PCI).

Introduzione

L’approccio tradizionale alla sicurezza di rete è stato quello di definire perimetri attorno a un gruppo di applicazioni. I firewall vengono utilizzati in queste perimetri per consentire o negare il traffico in base all'IP di origine e di destinazione indirizzi IP, pur mantenendo attendibili le applicazioni e il traffico contenuto perimetrale. Tuttavia, questa fiducia comporta dei rischi. Un malintenzionato interno al dominio o chiunque che comprometta il perimetro può muoversi liberamente all’interno della rete, accedere esfiltrare i dati, attaccare sistemi di terze parti e interferire con l’amministrazione sistemi diversi.

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

  • Gli indirizzi IP dei pod non rappresentano in modo adeguato l'identità carico di lavoro durante la connessione. In un ambiente Kubernetes, l'IP del pod vengono assegnati in modo temporaneo e vengono riciclati spesso man mano che i pod vengono e via.

  • Spesso è impossibile identificare un insieme di indirizzi IP piccolo e fisso per determinati host di destinazione. Gli indirizzi IP cambiano di frequente e variano in base regione e può essere preso da intervalli di grandi dimensioni o rappresentare cache, proxy CDN.

  • Più team che condividono lo stesso cluster multi-tenant, con un di IP di origine, potrebbero avere connettività esterna diversa i tuoi requisiti.

Cloud Service Mesh è il servizio completamente supportato distribuzione del servizio Istio open source mesh. Un mesh di servizi fornisce un modo uniforme per connettersi, gestire e proteggere la comunicazione con l'applicazione. I mesh di servizi adottano un approccio incentrato sull'applicazione e utilizzano identità di applicazioni attendibili anziché un indirizzo IP di rete incentrato l'importanza di un approccio umile.

Puoi eseguire il deployment di un mesh di servizi in modo trasparente, senza dover modificare il codice dell'applicazione. L'utilizzo di un mesh di servizi aiuta a disaccoppiare il lavoro di sviluppo responsabili della distribuzione e del rilascio di funzionalità dell'applicazione, dalle responsabilità degli amministratori di rete fornendo il controllo del comportamento della rete.

Cloud Service Mesh offre l'opzione di deployment proxy di forwarding autonomi,noti come gateway in uscita, sul perimetro del mesh. Questa guida spiega come combinare le funzionalità del proxy gateway in uscita con funzionalità Google Cloud per controllare, autorizzare e osservare il traffico in uscita dei carichi di lavoro con deployment in un cluster GKE.

componenti concettuali

Architettura di difesa in profondità

Il diagramma seguente mostra un'architettura che adotta un approccio alla difesa in profondità al controllo granulare del traffico in uscita per un cluster utilizzato team di sicurezza. I controlli si basano sia su Livello 4 (trasporto) e Livello 7 (applicazione) i controlli di rete.

architettura complessiva

L'architettura utilizza le risorse e i controlli seguenti:

  • R cluster GKE privato: I nodi in un cluster GKE privato hanno solo IP interno 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 il livello 4 (trasporto) alle connessioni da e verso i nodi in GKE in un cluster Kubernetes. Puoi applicare regole firewall VPC alle VM in base account di servizio o tag di rete.

  • Pool di nodi GKE con account di servizio diversi: questo consente di configurare firewall regole applicabili a seconda del pool di nodi a cui appartiene un nodo.

  • Kubernetes spazi dei nomi: Puoi creare spazi dei nomi per ogni team in modo da fornire l'isolamento controllo amministrativo. Gli amministratori di rete usano uno spazio dei nomi dedicato eseguire il deployment del gateway in uscita e configurare il routing a host esterni.

  • Kubernetes norme della rete: I criteri di rete consentono di applicare i controlli di livello 4 ai pod. Ogni criterio di rete ha ambito uno spazio dei nomi e può essere eseguito in modo più preciso a determinati pod in uno spazio dei nomi.

  • Un gateway in uscita: il traffico che esce dai pod all'interno del mesh viene indirizzato attraverso proxy gateway in uscita dedicati in esecuzione su nodi dedicati. Esegui il deployment gateway in uscita con Horizontal Pod Autoscaler per fare lo scale up e lo scale down del numero di repliche in base al traffico.

  • Criteri di autorizzazione: Puoi utilizzare i criteri di autorizzazione mesh per applicare i controlli di livello 7 (applicazione) al traffico tra i pod all'interno del mesh e al traffico che esce dal mesh.

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

  • Accesso privato Google: Questa opzione consente a nodi e pod nel cluster privato di accedere alle API di Google. ed eseguire il pull delle immagini Docker Container Registry.

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

Configurazione dei controlli del traffico in uscita

Se utilizzi il gateway in uscita per proteggere il traffico dalla rete mesh, configurare i controlli per la difesa in profondità descritti in .

Usa Private GKE con Cloud NAT

Laddove la sicurezza è importante, il primo requisito di molte organizzazioni è evitare di assegnare indirizzi IP pubblici ai propri carichi di lavoro. R cluster GKE privato soddisfi questo requisito. Puoi configurare in modalità VPC Native sui tuoi server in modo che ai pod e ai servizi vengano assegnati indirizzi IP nel VPC. Gli indirizzi IP dei pod nativi VPC sono instradabili in modo nativo all'interno rete VPC.

Alcuni carichi di lavoro potrebbero richiedere l'accesso a servizi esterni alla rete VPC. a internet. Consentire ai carichi di lavoro di connettersi a host esterni senza la necessità in modo che abbiano indirizzi IP pubblici, Cloud NAT per fornire la Network Address Translation (NAT).

Assicurati che Cloud NAT sia configurato in modo che un gateway in uscita può effettuare un numero sufficiente di connessioni simultanee destinazioni esterne. Puoi evitare l'esaurimento delle porte e i problemi con ritardi durante il riutilizzo della connessione impostando il numero minimo di porte per VM in modo appropriato. Vedi la panoramica su porte e indirizzi Cloud NAT per ulteriori dettagli. L'aumento del numero di repliche dei gateway in uscita può aiutare a ridurre le probabilità di conflitti di mappatura indipendenti 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 di Google i servizi di machine learning. Utilizza l'accesso privato Google con Zone DNS personalizzate per consentire la connettività da subnet VPC private alle API di Google utilizzando un set con quattro indirizzi IP. Quando si utilizzano questi indirizzi IP, non è necessario che i pod hanno indirizzi IP esterni e il traffico non esce mai dalla rete Google. Tu può usare private.googleapis.com (199.36.153.8/30) o restricted.googleapis.com (199.36.153.4/30), a seconda che tu sia utilizzando Controlli di servizio VPC.

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

Utilizzo Identità carico di lavoro è il metodo consigliato per consentire ai carichi di lavoro GKE di autenticare con le API di Google e per consentire agli amministratori di applicare il "privilegio minimo" autorizzazione i controlli tramite IAM.

Quando utilizzi l'accesso privato Google, Workload Identity e IAM, consente in modo sicuro ai pod del carico di lavoro di bypassare il gateway in uscita e di connettersi direttamente alle API e ai servizi Google.

Utilizza gli spazi dei nomi Kubernetes per il controllo amministrativo

Gli spazi dei nomi sono risorse organizzative utili negli ambienti in cui ci sono molti utenti, team o tenant. Possono essere considerati una sorta di e consentono la responsabilità amministrativa di gruppi di Kubernetes risorse da delegare a amministratori diversi.

Gli spazi dei nomi sono una funzionalità importante per l'isolamento del controllo amministrativo. Tuttavia, non forniscono, per impostazione predefinita, l'isolamento dei nodi o 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 mesh e le risorse collaterali possono limita la visibilità e l'accesso in base allo spazio dei nomi, all'identità e al livello 7 (applicazione) del traffico di rete.

Allo stesso modo, puoi utilizzare i criteri di rete di Kubernetes per consentire o negare connessioni di 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 diversi vantaggi. I nodi rivolti all'esterno possono utilizzare configurata con protezione avanzata, e configurare le regole firewall VPC per impedire ai carichi di lavoro di raggiungere per gli host esterni. La scalabilità automatica dei pool di nodi può essere eseguita in modo indipendente con il gestore della scalabilità automatica dei cluster.

Per consentire il controllo amministrativo separato del gateway in uscita, eseguine il deployment in una uno spazio dei nomi istio-egress dedicato. Tuttavia, gli spazi dei nomi sono un ambiente e non è possibile utilizzarle per controllare su quali nodi su cui viene eseguito. Per il controllo del deployment, utilizza un selettore nodi per il deployment del gateway in uscita, in modo che venga eseguito su nodi etichettati come dei membri del pool di nodi del gateway.

Assicurati che solo i pod del gateway possano essere eseguiti sui nodi gateway. Gli altri pod dovrebbero essere respinti dai nodi gateway, altrimenti i controlli in uscita potrebbero essere bypassati. È possibile impedire l'esecuzione dei carichi di lavoro su determinati nodi utilizzando incompatibilità e tolleranze. Devi incompatibile i nodi nel pool di nodi del gateway e aggiungere un'etichetta il deployment del gateway in uscita.

Applica le regole del firewall VPC a nodi specifici

Configuri il routing del mesh di servizi per indirizzare il traffico in uscita dai carichi di lavoro in esecuzione nel pool di nodi predefinito attraverso i gateway in uscita nel pool di nodi del gateway. Tuttavia, la configurazione del routing del mesh non essere considerata un confine di sicurezza, perché esistono vari modi in cui il carico di lavoro potrebbe bypassare i proxy mesh.

Per impedire ai carichi di lavoro delle applicazioni di connettersi direttamente a host esterni, Applicare regole firewall in uscita restrittive ai nodi nel pool di nodi predefinito. Applicare regole firewall separate ai nodi del gateway in modo che il gateway in uscita I pod in esecuzione su questi pod possono connettersi a host esterni.

Quando crei una regola firewall VPC, devi specificare le porte e i protocolli che la regola firewall consente o nega e la direzione a cui si applica. Le regole in uscita si applicano al traffico in uscita Le regole in entrata si applicano al traffico in entrata. Il valore predefinito per il traffico in uscita è allow mentre il valore predefinito 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 il traffico specifico se una VM è consentita, è consentito anche restituire il traffico utilizzando la stessa connessione.

Il seguente diagramma mostra come regole firewall separate possono essere applicate ai nodi in due diversi pool di nodi in base all'account di servizio assegnato al nodo. Nel in questo caso, una regola firewall predefinita deny all nega l'accesso in uscita per l'intero in un VPC. Per evitare di eseguire l'override delle regole firewall predefinite essenziali per il tuo un cluster per funzionare, la regola deny all deve utilizzare una priorità bassa come 65535 Viene applicata una regola firewall in uscita additiva e con priorità più alta ai nodi gateway per consentire la connessione diretta a host esterni sulle porte 80 e 443. Il pool di nodi predefinito non ha accesso agli host esterni.

pool di nodi firewall

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

Utilizza le funzionalità di Criteri di rete di Kubernetes di 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 a livello 4 (trasporto). Con i criteri di rete, puoi limitare il traffico in entrata e in uscita:

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

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

Il tutorial companion include i seguenti esempi di criteri di rete:

  • Consenti le connessioni in uscita dagli spazi dei nomi del carico di lavoro allo Spazi dei nomi istio-system e istio-egress. I pod devono poter connettersi verso 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 diversi team di applicazioni.
  • Consenti le connessioni in uscita dagli spazi dei nomi dei carichi di lavoro ai VIP per API di Google (esposte mediante l'accesso privato Google). Cloud Service Mesh fornisce una CA gestita e la espone come API, quindi i proxy sidecar devono possano connettersi. È anche probabile che alcuni carichi di lavoro necessitano dell'accesso alle API di Google.
  • Consenti connessioni in uscita dagli spazi dei nomi dei carichi di lavoro ai metadati GKE in modo che i proxy collaterali e i carichi di lavoro possano creare metadati query e l'autenticazione nelle API di Google.

Per impostazione predefinita, quando un proxy sidecar viene inserito in un pod del carico di lavoro, iptables sono programmate in modo che il proxy acquisisca tutti i TCP in entrata e in uscita per via del traffico. Tuttavia, come detto in precedenza, esistono modi in cui i carichi di lavoro bypassare il proxy. Le regole firewall VPC impediscono l'accesso diretto in uscita i nodi predefiniti che eseguono i carichi di lavoro. Puoi usare i criteri di rete Kubernetes garantire che non sia possibile uscire dall'esterno diretto dagli spazi dei nomi dei carichi di lavoro 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 in entrata che corrispondano ai criteri 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 al loro IP indirizzi IP esterni. Cloud Service Mesh assegna un'identità efficace e verificabile di certificato X.509 e per ogni carico di lavoro. Viene stabilita una comunicazione affidabile tra i carichi di lavoro usando i token di autenticazione Connessioni TLS reciproche (mTLS).

L'uso dell'autenticazione mTLS con un'identità ben definita per ogni applicazione consente di usare i criteri di autorizzazione della rete mesh per avere un controllo granulare sulle modalità dei carichi di lavoro possono comunicare con servizi esterni.

Sebbene il traffico possa uscire dalla rete mesh direttamente dai proxy sidecar, ti consigliamo di instradare il traffico attraverso i gateway in uscita come descritto in questa guida.

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

Gli amministratori di rete possono gestire centralmente i controlli utilizzando un server istio-egress per la configurazione mesh relativa al traffico in uscita. Come in precedenza Ti consigliamo di eseguire il deployment del gateway in uscita nello spazio dei nomi istio-egress. Tu può creare e gestire le voci di servizio, i gateway e i criteri di autorizzazione nello spazio dei nomi.

Richiedi configurazione esplicita delle destinazioni esterne

Assicurati che i proxy mesh siano programmati solo con route verso host esterni che sono definite in modo esplicito nel registro del mesh di servizi. Imposta il parametro modalità dei criteri del traffico in uscita a REGISTRY_ONLY in un valore predefinito risorsa collaterale per ogni spazio dei nomi. L'impostazione del criterio del traffico in uscita per il mesh non dovrebbe, da solo, essere considerato un controllo perimetrale sicuro.

Definisci destinazioni esterne con le voci di servizio

Configura Voci di servizio registrare esplicitamente gli host esterni nel registro dei servizi del mesh. Di per impostazione predefinita, le voci di servizio sono visibili a tutti gli spazi dei nomi. Utilizza la Attributo esportazioneTo per controllare a quali spazi dei nomi è visibile una voce di servizio. Voci di servizio determinare le route in uscita configurate nei proxy mesh, ma che di per sé non essere considerati un controllo sicuro per determinare quali a cui possono connettersi i carichi di lavoro host.

Configura il comportamento del gateway in uscita con la risorsa Gateway

Configurare il comportamento di bilanciamento del carico dei gateway in uscita utilizzando il metodo Gateway risorsa. Il bilanciatore del carico può essere configurato per un particolare insieme di host, protocolli e porte associati al deployment di un gateway in uscita. Per Ad esempio, un gateway potrebbe essere configurato per il traffico in uscita verso le porte 80 e 443 per qualsiasi host esterno.

In Cloud Service Mesh 1.6 e versioni successive, mTLS automatico è abilitato per impostazione predefinita. Con mTLS, un proxy sidecar client rileva automaticamente se server ha un file collaterale. Il lato client invia mTLS ai carichi di lavoro con file collaterali e invia traffico di testo normale ai carichi di lavoro senza file collaterali. Anche con mTLS, il traffico inviato al gateway in uscita dai proxy sidecar non automaticamente mTLS. a indicare il modo in cui le connessioni al gateway in uscita devi impostare la modalità TLS sulla risorsa Gateway. Se possibile, utilizza mTLS per le connessioni dai proxy sidecar gateway in uscita.

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

passaggio tls

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

Utilizza le funzionalità di Servizi virtuali e Regole di destinazione per configurare il routing del traffico dai proxy sidecar attraverso il traffico in uscita gateway a destinazioni esterne. I servizi virtuali definiscono le regole per la corrispondenza una certa quantità di traffico. Il traffico corrispondente viene quindi inviato a una destinazione. Destinazione le regole possono definire sottoinsiemi (ad esempio, il gateway in uscita o un host esterno) e come deve essere gestito il traffico quando viene instradato alla destinazione.

Utilizza un'unica regola di destinazione per consentire a più host di destinazione di e specificare come deve essere protetto il traffico dai proxy sidecar al gateway. Come come spiegato in precedenza, il metodo preferito è che i carichi di lavoro inviino testo richieste e del proxy sidecar per dare origine a una connessione mTLS gateway VPN ad alta disponibilità.

Utilizza una regola di destinazione per ogni host esterno per configurare il gateway in uscita verso 'upgrade' richieste HTTP semplici per utilizzare una connessione TLS (HTTPS) durante l'inoltro a la destinazione. L'upgrade di una connessione in testo normale a TLS è spesso definito come origine TLS.

Controlla l'ambito della configurazione proxy con la risorsa Sidecar

Configura un valore predefinito Risorsa collaterale 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 dei proxy in uscita. Una tipica configurazione minima può Includi 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 voci di servizio

La configurazione dei listener in uscita nei proxy sidecar non dovrebbe come controlli di sicurezza.

Una best practice consiste nell'utilizzare le risorse Sidecar per limitare le dimensioni del proxy configurazione. Per impostazione predefinita, ogni proxy sidecar in un mesh è configurato in modo da consentire per inviare il traffico a ogni altro proxy. Il consumo di memoria del file collaterale e il piano di controllo possono essere ridotti notevolmente dei proxy che rimandano solo agli host di cui hanno bisogno per comunicare con.

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 dell'accesso granulari per il traffico mesh. Puoi creare criteri per consentire o negare il traffico in base a proprietà dell'origine, della destinazione o del traffico stesso (ad esempio, un host o le intestazioni di una richiesta HTTP).

Consentire o negare le connessioni in base all'identità del carico di lavoro di origine. dello spazio dei nomi, la connessione al gateway in uscita deve essere autenticata mTLS. Le connessioni da file collaterali al gateway in uscita non utilizzano automaticamente mTLS, quindi la regola di destinazione per le connessioni al gateway deve indicare specificare ISTIO_MUTUAL Modalità TLS.

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

Per supportare i requisiti in uscita di diversi team e applicazioni, configurare il "privilegio minimo" separato di autorizzazione per spazio dei nomi carico di lavoro. Ad esempio, possono essere applicati criteri diversi al gateway in 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, poi consenti il traffico.

    esempio dei criteri di autorizzazione

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

    i criteri di autorizzazione utilizzando httpbin

Tutte le altre richieste vengono rifiutate.

Configura il gateway in uscita in modo che abbia origine le connessioni TLS (HTTPS) verso la destinazione

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

Affinché l'originazione TLS al gateway in uscita funzioni, i carichi di lavoro devono inviare richieste HTTP. Se il carico di lavoro avvia TLS, il gateway in uscita aggrega TLS su il TLS originale e le richieste al servizio esterno non andranno a buon fine.

Poiché i carichi di lavoro inviano richieste HTTP semplici, configura proxy sidecar per stabilire una connessione mTLS durante l'invio al gateway. Il gateway in uscita termina quindi la connessione mTLS e dà origine a una normale Connessione TLS (HTTPS) all'host di destinazione.

Originazione TLS al gateway in uscita

Questo approccio offre diversi vantaggi:

  • Puoi utilizzare un criterio di autorizzazione per consentire o negare il traffico in base a del carico di lavoro di origine e delle richieste.

  • Il traffico tra i pod dei carichi di lavoro e il gateway in uscita è criptato autenticati (mTLS) e il traffico tra il gateway in uscita e è crittografata (TLS/HTTPS).

  • All'interno della mesh, i proxy sidecar possono osservare e agire sulle proprietà di richieste HTTP (ad esempio, intestazioni), offrendo opzioni aggiuntive per osservabilità e controllo.

  • Il codice dell'applicazione può essere semplificato. Non è necessario che gli sviluppatori gestire certificati o librerie client HTTPS e il mesh di servizi può garantire una comunicazione sicura con crittografie standard e aggiornate.

  • Connessioni TLS che il gateway in uscita ha origine verso servizi esterni possono essere riutilizzate per il traffico da molti pod. Il riutilizzo della connessione è molto più è efficiente e riduce il rischio di raggiungere i limiti di connessione.

DNS, nomi host e caratteri jolly

Quando instrada, neghi o consenti il traffico in base all'host di destinazione, devono avere piena fiducia nell'integrità dei tuoi sistemi DNS per risolvere i nomi DNS all'indirizzo IP corretto. Nei cluster Kubernetes Engine, il servizio DNS di Kubernetes gestisce le query DNS e a sua volta delega le query esterne a GKE server di metadati DNS interno. Imposta il parametro dell'attributo risoluzione di voci di servizio al DNS durante l'instradamento a host esterni, in modo che i proxy sono responsabili delle query DNS.

Cloud Service Mesh può instradare 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 set comune di server. Ad esempio, se un singolo insieme di server può pubblicare i domini corrisponde a *.example.com, si può utilizzare un host con caratteri jolly.

Un gateway in uscita standard non può eseguire l'inoltro in base a criteri più generici e arbitrari host con caratteri jolly (ad esempio *.com) a causa di alcune limitazioni di Envoy proxy utilizzato da Istio. Envoy può solo instradare il traffico a host predefiniti, o all'indirizzo IP di destinazione originale di una richiesta. Quando si utilizza un gateway in uscita, l'IP di destinazione originale della richiesta viene perso perché viene sostituito con l'IP del gateway e la destinazione arbitraria. non possono essere preconfigurati.

Applicazione amministrativa dei criteri

Utilizza il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes

Solo gli amministratori autorizzati devono essere in grado di configurare i controlli del traffico in uscita. Configura Controllo degli accessi basato su ruoli (RBAC) di Kubernetes per evitare l'elusione non autorizzata dei controlli in uscita. Applicare i ruoli RBAC in modo che solo gli amministratori di rete possono 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 del carico di lavoro sui nodi gateway. Tuttavia, per impostazione predefinita, non c'è nulla che impedisca i carichi di lavoro il deployment con una tolleranza per i nodi gateway e quindi controlli in uscita. Se è possibile applicare in modo forzato controllo amministrativo sulle pipeline di deployment, puoi usarle per applicare restrizioni all'uso di determinate chiavi di tolleranza.

Un altro approccio consiste nell'utilizzare Controllo di ammissione Kubernetes. Anthos include un componente chiamato Policy Controller che funge da controller di ammissione Kubernetes e convalida che i deployment e che soddisfino i vincoli del criterio da te specificati.

Assicurati che il traffico venga registrato

Spesso è necessario registrare tutto il traffico che attraversa i perimetri della rete. Il logging del traffico è essenziale se devi essere in grado di dimostrare la conformità con comuni in materia di protezione dei dati. I log sul traffico vengono inviati direttamente Cloud Logging e accessibile dalle dashboard di Cloud Service Mesh nella console Google Cloud. Puoi filtrare i log in base a vari attributi, tra cui origine/destinazione, identità, degli spazi dei nomi, attributi del traffico e latenza.

Per consentire un semplice debug con kubectl, attiva il logging del traffico per stdout quando installando Cloud Service Mesh utilizzando Impostazione accessLogFile.

Log di controllo vengono inviati a Cloud Logging ogni volta che la CA Mesh crea un certificato per carico di lavoro.

Valuta la possibilità di utilizzare un cluster separato per i gateway in uscita all'interno di mesh multi-cluster

Cloud Service Mesh può essere di cui è stato eseguito il deployment in più cluster GKE. Le mesh multi-cluster introducono nuove possibilità per il controllo del traffico in uscita e anche da alcune limitazioni.

Anziché eseguire il deployment del gateway in uscita in un pool di nodi dedicato, puoi eseguire il deployment il gateway a un cluster separato che non esegue i normali carichi di lavoro. L'utilizzo di un un cluster separato fornisce un isolamento simile tra carichi di lavoro e gateway, evitando al tempo stesso la necessità di incompatibilità e tolleranze. Il gateway in uscita può il cluster separato con gateway in entrata o altri servizi centrali.

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

Passaggi successivi