Questo documento mostra gli ingegneri di rete, di piattaforma e della sicurezza che amministrano i cluster Kubernetes come gestire la comunicazione esterna da cluster a cluster utilizzando i gateway in entrata e in uscita di Anthos Service Mesh. Il documento descrive come utilizzare Anthos Service Mesh per criptare e proteggere il traffico in uscita (in uscita) dai carichi di lavoro distribuiti su un cluster Kubernetes a carichi di lavoro in esecuzione in un altro cluster Kubernetes. Le tecniche descritte mostrano come utilizzare certificati separati per la comunicazione reciproca, criptata e tra cluster.
Le indicazioni contenute in questo documento derivano dai requisiti del cliente relativi all'utilizzo di una specifica autorità di certificazione (CA) principale per le comunicazioni intra-cluster. Potresti trovare questi requisiti in mercati altamente regolamentati, come i servizi finanziari o la sanità. Le indicazioni qui presentate consentono anche l'utilizzo di endpoint diversi dai cluster Kubernetes, come fornitori di liquidazione finanziaria o un'interfaccia API per i dati sensibili. Queste indicazioni sono particolarmente pertinenti per le organizzazioni che devono ottemperare a rigorosi criteri di sicurezza e controllo.
Puoi utilizzare e gestire le comunicazioni criptate senza toccare i carichi di lavoro in esecuzione nei cluster. Per indicazioni su come configurare i tuoi cluster, segui il tutorial correlato.
Introduzione
Quando le aziende iniziano ad adottare Kubernetes per la prima volta, spesso partono da un singolo cluster in cui la maggior parte delle comunicazioni rimane all'interno del cluster. Presto, l'interazione cross-namespace diventerà sempre più importante, ed è per questo che un provider di criteri di rete come Calico o Cilium può essere d'aiuto. Tuttavia, con la crescita degli ambienti container, diventa sempre più importante garantire la comunicazione sicura tra i servizi esterni e i container in esecuzione all'interno dei cluster Kubernetes.
I criteri di rete sono un ottimo modo per affrontare concetti di sicurezza tradizionali come la creazione di regole firewall interne sul cluster, ma hanno un uso limitato al di fuori del cluster. È possibile consentire di raggiungere solo un indirizzo IP specifico, ma non è disponibile alcun controllo sui contenuti o sull'identità. Di conseguenza, è necessario un concetto più versatile, che ti aiuti anche a criptare il traffico verso altri servizi esterni. Il seguente diagramma offre un approccio.
Nel mondo delle applicazioni, la crittografia viene generalmente eseguita utilizzando TLS (Transport Layer Security). Ciò significa che puoi criptare il traffico utilizzando un certificato privato (segreto) con una controparte pubblica, come mostrato nel diagramma precedente. La parte ricevente detiene il certificato pubblico, che viene utilizzato per verificare che le informazioni provengano da una fonte attendibile. Il traffico web HTTPS utilizza TLS per garantire comunicazioni sicure e criptate tra un client e un server web. In questo caso, il certificato pubblico proviene da un emittente attendibile (come Google Trust Services), chiamato anche CA, che fa parte dell'infrastruttura a chiave pubblica (PKI). TLS verifica l'identità del server, ma non verifica l'identità del client.
Nei casi in cui il client stesso deve essere verificato, è richiesta l'autenticazione reciproca (mTLS). mTLS viene utilizzata quando sia il mittente che il destinatario devono identificarsi presso l'altra parte, come mostrato nel seguente diagramma.
Questo metodo viene spesso utilizzato per le applicazioni che richiedono un ulteriore livello di sicurezza. Nel settore finanziario e per le informazioni che consentono l&PII;identificazione personale, gli enti regolatori spesso richiedono mTLS.
Anthos Service Mesh
Anthos Service Mesh è una soluzione mesh di servizi gestita da Google basata su OSS Istio. Ciò significa che è compatibile al 100% con l'API Istio. Anthos Service Mesh può fornire la funzionalità mTLS a livello di piattaforma anziché all'interno del codice dell'applicazione, il che significa che può essere applicato ai servizi senza che tu debba ricodificare ogni servizio. Anche operazioni come la rotazione dei certificati fanno parte di Anthos Service Mesh. Questo documento è incentrato su mTLS e sulle funzionalità di comunicazione esterna di Anthos Service Mesh. Esistono molte altre funzionalità, come fault injection, bilanciamento del carico avanzato e gestione degli errori.
Instradando tutto il traffico tramite proxy sidecar (Envoy), i mesh di servizi come Anthos Service Mesh alleggeriscono allo sviluppatore attività banali (ma importanti) come la crittografia e la gestione dei certificati. Grazie all'utilizzo di un proxy trasparente, i mesh di servizi possono attivare potenti funzioni L7 come il routing delle chiamate HTTP e HTTPS in base alle informazioni dell'intestazione. Tuttavia, Anthos Service Mesh consente anche l'incapsulamento e la crittografia del traffico, contribuendo a migliorare la sicurezza.
Configurazione di esempio: comunicazione MySQL tra cluster
Puoi utilizzare questo scenario per garantire una comunicazione sicura e affidabile tra i servizi in cluster diversi. In questo esempio, l'applicazione client MySQL comunica con un carico di lavoro DB del server MySQL in esecuzione in un cluster Kubernetes diverso, come mostrato nel diagramma seguente.
Sebbene i mesh di servizi funzionino spesso in OSI L7, puoi anche utilizzare alcune delle loro funzionalità per controllare le comunicazioni L4.
Ecco ciò che serve per far funzionare l'idea:
- Le comunicazioni tra applicazioni e cluster devono essere criptate.
- Le comunicazioni client e server devono essere verificate reciprocamente (mTLS).
- Non è necessario modificare i carichi di lavoro client e server.
Anche se puoi configurare il database MySQL in modo che accetti solo connessioni criptate, questa configurazione richiede la modifica del client del database, sul quale potresti non avere il controllo completo.
Ci sono diversi modi per soddisfare questi requisiti utilizzando Anthos Service Mesh. Un modo è creare un piano di controllo Istio condiviso tra i cluster e fare in modo che i servizi comunichino tra loro perché appartengono a un unico mesh di servizi logico. Puoi farlo per i cluster GKE abilitati per Anthos utilizzando Anthos Service Mesh in una configurazione di singoli progetti o più progetti.
Tuttavia, poiché è necessario disporre di una catena di attendibilità separata per la comunicazione cluster-to-cluster, puoi utilizzare l'approccio del gateway in uscita <–> gateway in entrata utilizzando mTLS.
I gateway in uscita e in entrata sono proxy Envoy che si trovano ai confini della rete mesh.
Puoi configurarle per controllare il flusso del traffico in entrata e in uscita dalla rete mesh di servizi.Questo metodo funziona anche per gli endpoint non Kubernetes e consente di utilizzare certificati diversi per le comunicazioni criptate.
Configurare il traffico in entrata e in uscita da Anthos Service Mesh
Nello scenario precedente, devi gestire la comunicazione sicura da cluster a cluster utilizzando i gateway in uscita e in entrata tra i rispettivi cluster.
Che cos'è un gateway in uscita?
In uscita indica il traffico che esce dal mesh di servizi. Un gateway in uscita fornisce un punto di uscita controllato per quel traffico.
Senza configurazione aggiuntiva, per un pod in cui è stato inserito il proxy sidecar, il traffico destinato a un servizio che risiede al di fuori del mesh (ad esempio un servizio API pubblico) viene instradato dal pod al proxy sidecar. In un cluster GKE (e nella maggior parte degli altri cluster Kubernetes), l'indirizzo IP del nodo utilizza un NAT per tradurre il traffico proxy sidecar, che passa direttamente all'indirizzo esterno del servizio. Il seguente diagramma mostra questa configurazione.
In questo diagramma, il client chiama il lato server, che rappresenta il servizio esterno. Per il mesh, il traffico è in uscita, quindi devi configurare il gateway in uscita sul lato client (ad esempio, il client MySQL).
Devi configurare il gateway in uscita in modo che inoltri la chiamata al servizio esterno. Dopo che il servizio esterno ha elaborato la richiesta e restituisce la risposta, passa di nuovo attraverso il gateway in uscita per tornare al proxy client e infine al pod che effettua la chiamata (ad esempio, il client MySQL).
Che cos'è un gateway in entrata?
In entrata indica il traffico che entra nel mesh di servizi. Un gateway in entrata espone i servizi al mondo esterno (ovvero al di fuori del mesh di servizi) e gestisce il modo in cui questi servizi devono essere accessibili. È paragonabile a un oggetto Kubernetes Ingress.
Con un gateway in entrata, puoi definire un singolo punto di ingresso controllato in cui il traffico entra nel mesh. Inizialmente, il traffico entra attraverso il bilanciatore del carico, che viene creato definendo un servizio gateway in entrata. Da qui, la richiesta viene inoltrata al proxy sidecar e da questo proxy al pod. Il pod può elaborare la richiesta e restituire la risposta utilizzando la stessa route in senso inverso. Il seguente diagramma mostra questa configurazione.
Questo è il traffico in entrata verso il mesh dell'altro cluster (VPC 2). Di conseguenza, devi configurare il gateway in entrata sul lato server per gestire queste chiamate.
La configurazione lato server del gateway in entrata inoltra la chiamata al servizio interno. Dopo che il servizio interno ha elaborato la richiesta, la risposta che restituisce torna al client attraverso il gateway in entrata.
Combinazione di funzionalità in uscita e in entrata per TLS reciproco
Come accennato in precedenza, per il lato client è necessario definire un gateway in uscita che funga da punto di uscita controllato per il mesh di servizi. Per assicurarti che il traffico che lascia il mesh attraverso il gateway sia criptato tramite mTLS, puoi utilizzare una tecnica chiamata origine TLS. Configura un gateway in uscita per eseguire l'originazione TLS per il traffico verso servizi esterni.
Quando il traffico che esce dal mesh di servizi dal lato client è criptato, devi assicurarti che il lato server sia in grado di identificarsi con il client e decifrare il traffico criptato.
Per farlo, devi utilizzare il gateway in entrata come singolo punto di ingresso nel mesh. Configura il gateway in entrata in modo che preveda traffico con crittografia reciproca.
Panoramica dell'architettura mesh
Il seguente diagramma descrive cosa è necessario per implementare questo concetto per lo scenario MySQL, senza modificare nulla nell'applicazione o nel server.
In VPC 1, puoi osservare che il cluster client che esegue il client MySQL accede al server. Il server si trova in VPC 2.
Il lato client è più impegnativo della configurazione rispetto al lato server, perché devi eseguire un po' più di corrispondenza e routing del traffico per garantire che l'applicazione utilizzi il gateway in uscita. Tuttavia, questa configurazione prevede uno sforzo giorno zero, perciò devi farlo una sola volta. Una volta implementata, è abbastanza facile da gestire.
Un vantaggio dell'implementazione di questo concetto con Kubernetes è che tutti gli elementi di configurazione sono archiviati in file YAML. Ciò significa che l'intero costrutto può essere utilizzato in un repository con controllo delle versioni, che consente di tenere traccia delle modifiche e di ripristinarle facilmente, se necessario.
Lato client
Questa sottosezione esamina la configurazione lato client. Ogni elemento che vedi nel diagramma ha una funzione distinta nel mesh per controllare in che modo il traffico viene instradato attraverso il gateway in uscita per raggiungere la sua destinazione, il server MySQL.
Il routing del traffico è solo una parte della funzionalità richiesta. Altri elementi controllano la crittografia del traffico, in modo completamente trasparente, per garantire che la comunicazione sia sempre sicura. Nelle sezioni seguenti vengono esaminati gli elementi per comprenderne meglio il ruolo e la funzione in questo scenario.
Accesso al servizio
Un mesh di servizi crea il proprio registro di servizi in un cluster Kubernetes. Il piano di controllo utilizza questo registro per configurare i proxy sidecar come tabella di routing. I servizi in esecuzione in Kubernetes vengono rilevati e aggiunti al registro del mesh di servizi. I servizi non in esecuzione all'interno del cluster Kubernetes non possono essere rilevati automaticamente, ma possono essere definiti utilizzando ServiceEntries. In questo modo, il client può utilizzare una voce come nome host per connettersi a servizi esterni.
In Anthos Service Mesh, vengono utilizzati nomi di dominio completi (FQDN) per identificare tutti i servizi. Il nome di dominio completo è la parte più importante di questo costrutto perché i certificati sono basati sul nome host. Sebbene sia possibile modificare il nome di dominio completo, devi anche rigenerare tutti i certificati necessari.
Per abilitare la comunicazione, devi configurare il mesh di servizi per ascoltare le chiamate verso il servizio esterno in modo da instradare correttamente il traffico. La rete mesh consente di definire una voce di servizio che punta a quel servizio esterno.
Questo costrutto è chiamato MESH_EXTERNAL ed è ideale per questi casi d'uso. Potresti anche voler specificare ciò che stai cercando. Poiché si tratta di un caso d'uso L4 e puoi controllare solo l'indirizzo IP e la porta, devi comunicare al mesh il protocollo e le porte specifiche, in questo caso TCP e porta 3306 (la porta standard del protocollo MySQL). Inoltre, la controparte lato server (come mostrato nel diagramma precedente) è in ascolto sulla porta 13306 (il gateway in uscita del cluster del server). Infine, devi indicare alla voce servizio di acquisire il traffico
con questo tag della porta.
La seguente voce di servizio YAML di esempio illustra questa configurazione:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: mysql-external
spec:
hosts:
- mysql.fqdn.example
location: MESH_EXTERNAL
ports:
- number: 3306
name: tcp
protocol: TCP
- number: 13306
name: tls
protocol: TLS
resolution: DNS
endpoints:
- address: mysql.fqdn.example
ports:
tls: 13306
Con il campo hosts puoi impostare il nome di dominio completo del servizio esterno oppure specificare che il campo location sia MESH_EXTERNAL. Devi anche specificare i valori ports utilizzati dal servizio esterno, in questo caso 13306 e 3306.
13306 sarà la porta esposta dal gateway in entrata lato server. È importante specificare entrambi in questa voce di servizio. Per il protocollo, devi specificare TLS, perché questa connessione fornisce una comunicazione TLS basata su L4.
Una volta definita la voce di servizio, il mesh può rimanere in ascolto delle chiamate e modificare il routing in base a queste regole.
Le voci dei servizi devono essere basate su voci DNS o IP esistenti, il che significa che il nome DNS deve essere già risolvibile da un server DNS. Ad esempio, puoi utilizzare un servizio DNS principale all'interno di Kubernetes e aggiungervi voci che non sono già presenti in kube-dns. Non puoi utilizzare la voce del servizio per creare una voce DNS.
Servizio virtuale
Il servizio virtuale è una definizione utilizzata per influire sui pattern di routing del traffico. Puoi utilizzare il servizio virtuale per assicurarti che le chiamate dal client MySQL alla voce del servizio vengano instradate al gateway in uscita. Puoi quindi configurare un servizio virtuale per instradare il traffico in base a fattori molto diversi. Nel caso d'uso L7, questi fattori vanno oltre il routing del traffico. Ad esempio, puoi indicare al servizio virtuale come reagire se un obiettivo non è raggiungibile. Questo esempio utilizza un sottoinsieme di questa funzionalità per instradare il traffico corrispondente solo al gateway in uscita per un'ulteriore elaborazione.
Il diagramma precedente mostra come utilizzare il servizio virtuale per instradare il traffico dal pod attraverso il proxy al gateway in uscita e dal gateway in uscita al servizio esterno.
Devi anche specificare la porta del gateway in uscita (rivolta all'esterno),
che è 15443 per impostazione predefinita. Questa porta viene impostata sul gateway in uscita dopo la creazione. Puoi scegliere qualsiasi altra porta libera, ma dovresti applicare una patch al gateway per aprire la porta scelta.
Il seguente snippet di codice mostra l'aspetto di una definizione di servizio virtuale:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: direct-mysql-through-egress-gateway
spec:
hosts:
- mysql.fqdn.example
gateways:
- istio-egressgateway-mysql
- mesh
tcp:
- match:
- gateways:
- mesh
port: 3306
route:
- destination:
host: istio-egressgateway.istio-system.svc.cluster.local
subset: mysql
port:
number: 15443
weight: 100
- match:
- gateways:
- istio-egressgateway-mysql
port: 15443
route:
- destination:
host: mysql.fqdn.example
port:
number: 13306
weight: 100
Il campo hosts che contiene l'URL di nome di dominio completo viene utilizzato per applicare le regole di corrispondenza in modo specifico all'URL specificato. La prima clausola match è definita nel mesh, che è una parola chiave riservata e si applica a tutti i gateway all'interno del mesh. Il
primo blocco route viene definito per indicare al mesh cosa fare se la corrispondenza è vera.
In questo caso, invierai il traffico corrispondente al gateway in uscita. Qui è definita la porta in uscita, oltre alla ponderazione della route. Il blocco
menziona anche un valore subset, che definirai in seguito.
La seconda clausola match viene applicata al gateway in uscita. Il secondo blocco route aggiunto alla seconda clausola match configura il mesh in modo che invii il traffico al cluster del server in entrata utilizzando il campo host con il nome di dominio completo in entrata e specificando la porta 13306.
Per il passaggio successivo, devi programmare l'inserimento del certificato nel gateway affinché la comunicazione mTLS funzioni.
Regole di destinazione
Ora che il traffico è stato identificato correttamente (voce di servizio) e instradato dal pod attraverso il proxy al gateway (servizio virtuale), il passaggio successivo consiste nella crittografia del traffico. Puoi utilizzare le regole di destinazione per criptare il traffico. Queste regole in un mesh di servizi vengono applicate al traffico dopo il routing e vengono utilizzate per introdurre il bilanciamento del carico e altre funzionalità di gestione del traffico.
In questo caso, utilizzerai le regole di destinazione per definire un pattern di bilanciamento del carico standard e anche per aggiungere certificati per abilitare gli endpoint utilizzando la comunicazione mTLS. Questo passaggio viene eseguito abbinando il nome di dominio completo del server MySQL, esposto tramite il gateway in entrata del cluster di server e definendo una regola mTLS.
La definizione seguente è un esempio di questa regola di destinazione:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: egressgateway-for-mysql
spec:
host: istio-egressgateway.istio-system.svc.cluster.local
subsets:
- name: mysql
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 15443
tls:
mode: ISTIO_MUTUAL
sni: mysql.fqdn.example
Il campo host è impostato sul nome di dominio completo del cluster del gateway in uscita. La prima regola di destinazione esegue la crittografia del mesh interno del traffico, utilizzando la modalità ISTIO_MUTUAL (utilizzando il nome di dominio completo del gateway in uscita). Nello snippet di codice definisci una subset, che viene utilizzata per creare il bilanciamento del carico round robin e per impostare (sovrascrivere) la porta su 15443. Il gateway in uscita utilizza questa porta per inviare il traffico.
È importante impostare il campo tls correttamente perché definisce il criterio mesh interno (ISTIO_MUTUAL). Nel campo sni (indicazione nome servizio), aggiungi il nome di dominio completo del gateway in entrata dal cluster del server.
La seconda regola di destinazione cripta il traffico con i certificati CA radice forniti personalizzati, prima di inviarli attraverso il gateway in uscita:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: originate-mtls-for-mysql
spec:
host: mysql.fqdn.example
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 13306
tls:
mode: MUTUAL
credentialName: client-credential
sni: mysql.fqdn.example
Il campo host è impostato di nuovo sul nome di dominio completo esterno. Il campo trafficPolicy imposta la modalità del bilanciatore del carico su ROUND_ROBIN. Inoltre, imposta la porta su 13306 e la modalità tls su MUTUAL, poiché ora stai utilizzando i certificati CA radice personalizzati e la controparte, il gateway in entrata che utilizza tls MUTUAL, deve identificarsi utilizzando gli stessi certificati CA radice firmati. Utilizzando questa porta, il traffico può scorrere attraverso il cluster di server attraverso il gateway in entrata per raggiungere il database MySQL.
La crittografia con i certificati CA radice personalizzati viene in genere eseguita tramite Envoy Secret Discovery Service (SDS) utilizzando un secret in Kubernetes che contiene i certificati. Puoi aggiungere il nome del secret
alla regola di destinazione utilizzando il campo credentialName.
In sintesi, il traffico ora funziona come segue:
- Viene emesso da MySQL in modo trasparente verso un nome di dominio completo esterno. Questo nome di dominio completo esiste nella registrazione mesh.
- Viene criptato tramite una regola di destinazione che utilizza certificati mesh interni.
- Viene instradato al gateway da un servizio virtuale.
- Viene criptata utilizzando una CA radice personalizzata in base a una regola di destinazione (diversa dalla CA mesh utilizzata per i certificati mesh).
- Viene inoltrato attraverso il gateway in uscita in modalità mTLS.
Lato server
In questo scenario, il lato server è più facile da configurare rispetto al lato client. Tutto ciò di cui ha bisogno è un gateway in entrata e una voce di servizio virtuale per instradare il traffico al server DB MySQL, come mostrato nel diagramma seguente.
Il gateway in entrata del cluster di server
Il gateway in entrata sta esponendo la porta 13306. Può essere qualsiasi porta, ma in questo caso viene aggiunto "1" davanti alla porta MySQL standard per una più facile identificazione. Per motivi di sicurezza, non è consigliabile esporre la porta MySQL standard (3306) direttamente a internet.
Poiché il gateway in entrata Istio predefinito non è in ascolto sulla porta 13306, devi aggiungere questa funzionalità. Lo snippet di codice nell'esempio seguente porta 13306 al gateway:
[{
"op": "add",
"path": "/spec/ports/0",
"value": {
"name": "tls-mysql",
"protocol": "TCP",
"targetPort": 13306,
"port": 13306
}
}]
Puoi archiviare questo codice in un file JSON e utilizzarlo con il comando patch kubectl per applicarlo al servizio gateway in entrata.
Per elaborare correttamente il traffico, il gateway in entrata deve essere configurato in modalità MUTUAL.
A questo punto, il gateway in entrata decripta il traffico in entrata utilizzando il certificato dell'archivio di credenziali e invia il traffico al mesh, dove i certificati interni del mesh vengono utilizzati per ricriptare il traffico. Il seguente snippet di codice di esempio mostra come potrebbe essere configurato:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway-mysql
spec:
selector:
istio: ingressgateway # Istio default gateway implementation
servers:
- port:
number: 13306
name: tls-mysql
protocol: TLS
tls:
mode: MUTUAL
credentialName: mysql-credential
hosts:
- "mysql.fqdn.example"
In questo esempio, nel campo selector viene utilizzato il gateway in entrata Istio standard. Utilizzando il campo servers, puoi impostare i valori della porta number (13306) e protocol (TLS) che il traffico in entrata dovrebbe prevedere.
È importante assegnare alla porta un nome univoco,
Definisci tls e fornisci un secret contenente il certificato firmato dalla stessa CA radice utilizzato con il gateway in uscita utilizzando il campo credentialName.
Il certificato deve essere archiviato in un secret Kubernetes.
Infine, vuoi trovare il traffico che indirizza il nome di dominio completo DB MySQL. La risoluzione del nome per questo nome di dominio completo impostato in hosts deve essere impostata sull'indirizzo IP pubblico del gateway in entrata.
Il servizio virtuale del cluster di server
Dopo che il traffico è entrato nel mesh tramite la porta 13306, proveniente dal gateway di uscita del cluster client (originatore), devi identificare questo traffico e assicurarti che raggiunga il server DB MySQL. Per farlo, definisci un
servizio virtuale:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: mysql-virtual-service
spec:
hosts:
- "mysql.fqdn.example"
gateways:
- gateway-mysql
tcp:
- route:
- destination:
port:
number: 3306
host: mysql.default.svc.cluster.local
Per inviare il traffico al servizio MySQL DB, devi controllare di nuovo l'host di nome di dominio completo utilizzando il campo hosts. Inoltre, devi utilizzare il campo gateways per configurare dove applicare questa definizione di servizio virtuale. Questo è l'oggetto gateway che hai definito nel file YAML precedente. Imposta il campo tcp, perché si tratta di traffico L4, e imposta il campo route in modo che punti al servizio Kubernetes DB MySQL. Devi specificare il nome del servizio nel campo host utilizzando il nome di dominio completo interno del cluster Kubernetes.
Il database MySQL può ricevere richieste dal client sulla porta 3306. Il traffico attraversa il proxy sidecar del server MySQL DB. Per il server DB MySQL appare come una richiesta locale non criptata di accesso al database.
Dopo che il server ha risposto alla chiamata, il traffico torna al client utilizzando la stessa route e per il client sembra che un database locale abbia appena risposto alla sua chiamata.
Il traffico viene criptato tre volte utilizzando certificati diversi che passano da client a server, il che contribuisce a proteggere la comunicazione client-server.
La prima volta che il traffico viene criptato o decriptato all'interno del mesh sul lato client, con certificati che utilizzano la CA del mesh.
La seconda volta che il traffico viene criptato quando si lascia il mesh dal gateway in uscita, viene utilizzato un certificato di una CA radice personalizzata. Quindi il traffico viene autenticato e decriptato sul gateway in entrata utilizzando un certificato firmato dalla stessa CA radice personalizzata.
L'ultima (terza) volta che il traffico è stato criptato o decriptato all'interno del mesh sul lato server durante il passaggio dal gateway in entrata al server MySQL. Anche in questo caso (perché è un mesh interno) vengono utilizzati i certificati della CA mesh.
In questo scenario, la comunicazione tra i due cluster doveva essere criptata utilizzando la CA radice menzionata. Applicando questa configurazione, è possibile gestire questa parte separatamente e in modo indipendente dai certificati interni del mesh e dall'applicazione stessa.
Grazie a questo passaggio aggiuntivo, questa configurazione consente inoltre di ruotare facilmente questi certificati regolarmente senza modificare la CA mesh dei rispettivi cluster Kubernetes.
Passaggi successivi
- Prova il tutorial sulle creatività companion.
- Consulta la guida alla protezione di GKE.
- Scopri come gestire configurazione e criteri nell'intera infrastruttura con Config Management.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.