Questo documento mostra gli ingegneri di rete, piattaforma e 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 contribuire a 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 le comunicazioni reciproche, criptate e da cluster a cluster.
Le indicazioni contenute in questo documento derivano dai requisiti del cliente relativi all'utilizzo di una specifica autorità di certificazione (CA) radice per le comunicazioni tra cluster. Questi requisiti potrebbero capitare in mercati altamente regolamentati, come quelli dei servizi finanziari o della sanità. Le linee guida qui presentate consentono anche l'utilizzo di endpoint diversi dai cluster Kubernetes, come provider di liquidazioni finanziarie o un'interfaccia API per i dati sensibili. Queste linee guida sono particolarmente pertinenti per le organizzazioni che devono ottemperare a criteri rigorosi per la sicurezza e il 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 cluster singolo, in cui la maggior parte delle comunicazioni rimane all'interno di quel cluster. Presto, l'interazione tra spazi dei nomi diventa sempre più importante, ed è qui che può essere utile un provider di criteri di rete come Calico o Cillium. Tuttavia, man mano che gli ambienti container crescono, diventa sempre più importante garantire che la comunicazione possa avvenire in modo sicuro 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 al cluster, ma hanno un uso limitato all'esterno del cluster. Puoi consentire di raggiungere solo un indirizzo IP specifico, ma non è disponibile alcun controllo sui contenuti o sull'identità. Pertanto, è richiesto un concetto più versatile, che consenta anche di criptare il traffico verso altri servizi esterni. Il seguente diagramma offre un approccio.
Nel mondo delle applicazioni, la crittografia viene generalmente eseguita mediante 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), noto anche come 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 anche il client stesso deve essere verificato, è richiesta l'autenticazione reciproca (mTLS). mTLS viene utilizzata quando sia il mittente che il destinatario devono identificarsi con l'altra parte, come mostrato nel diagramma seguente.
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'identificazione personale (PII), 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 applicata 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 la fault injection, il bilanciamento del carico avanzato e la gestione degli errori.
Instradando tutto il traffico tramite proxy side-car (Envoy), i mesh di servizi come Anthos Service Mesh sollevano lo sviluppatore da attività banali (ma importanti) come la crittografia e la gestione dei certificati. Utilizzando 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, che possono contribuire a migliorare la sicurezza.
Configurazione di esempio: comunicazione MySQL tra cluster
Puoi utilizzare questo scenario per avere comunicazioni sicure e attendibili tra servizi in cluster diversi. In questo esempio, l'applicazione client MySQL comunica con un carico di lavoro DB server MySQL in esecuzione in un cluster Kubernetes diverso, come mostra il seguente diagramma.
Sebbene i mesh di servizi funzionino spesso in OSI L7, puoi anche utilizzare alcune delle loro funzionalità per controllare le comunicazioni L4.
Ecco ciò di cui hai bisogno per far funzionare l'idea:
- La comunicazione tra applicazioni e cluster deve essere criptata.
- Le comunicazioni client e server devono essere verificate reciprocamente (mTLS).
- Non è necessario modificare i carichi di lavoro client e server.
Sebbene sia possibile configurare il database MySQL in modo che accetti solo connessioni criptate, questa configurazione richiede la modifica del client del database, su cui potresti non avere il controllo completo.
Esistono 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 singolo mesh di servizi logico. Puoi eseguire questa operazione per i cluster GKE abilitati per Anthos utilizzando Anthos Service Mesh nell'impostazione di un singolo progetto o di più progetti.
Tuttavia, poiché è necessario disporre di una catena di attendibilità separata per la comunicazione da cluster a cluster, puoi utilizzare l'approccio 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 configurarli per controllare il flusso di traffico in entrata e in uscita dal mesh di servizi.Questa operazione funziona anche per gli endpoint non Kubernetes e consente di utilizzare certificati diversi per la comunicazione criptata.
Configura il traffico in uscita e in entrata di Anthos Service Mesh
Nello scenario precedente, devi gestire la comunicazione sicura da cluster a cluster utilizzando 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, questo traffico è in uscita, quindi devi configurare il gateway in uscita sul lato client (ad esempio, il client MySQL).
Devi configurare il gateway in uscita per inoltrare la chiamata al servizio esterno. Dopo che il servizio esterno ha elaborato la richiesta e restituisce la risposta, passa nuovamente attraverso il gateway in uscita al proxy client e, infine, al pod che esegue 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 (ossia 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 quest'ultimo viene inoltrata 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 è traffico in entrata verso il mesh dell'altro cluster (VPC 2). Pertanto, per gestire queste chiamate, devi configurare il gateway in entrata sul lato server.
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 delle funzionalità di traffico in uscita e in entrata per TLS reciproco
Come accennato in precedenza, per il lato client devi definire un gateway in uscita che funga da punto di uscita controllato per il mesh di servizi. Per assicurarti che il traffico in uscita dal mesh attraverso il gateway sia criptato da mTLS, puoi utilizzare una tecnica chiamata originazione TLS. Configura un gateway in uscita per eseguire l'originazione TLS per il traffico verso i servizi esterni.
Quando il traffico che esce dal mesh di servizi dal lato client è criptato, devi assicurarti che il lato server possa identificarsi con il client e decifrare il traffico criptato.
Per questo, devi utilizzare il gateway in entrata come singolo punto di ingresso nel mesh. Configura il gateway in entrata in modo che preveda il traffico con crittografia reciproca.
Panoramica dell'architettura mesh
Il seguente diagramma descrive cosa è necessario per implementare questo concetto nello scenario MySQL, senza modificare nulla nell'applicazione o nel server.
In VPC 1, puoi vedere che il cluster client che esegue il client MySQL accede al server. Il server si trova in VPC 2.
Il lato client ha un carico maggiore di configurazione rispetto al lato server perché è necessario eseguire un po' più di corrispondenza e routing del traffico per garantire che l'applicazione utilizzi il gateway in uscita. Tuttavia, questa configurazione prevede zero giorni, il che significa che devi eseguirla soltanto una 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 ti 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, completamente trasparente, per garantire che la comunicazione sia sempre sicura. Le sezioni seguenti esaminano gli elementi per comprenderne meglio il ruolo e il funzionamento in questo scenario.
Voce di 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 automaticamente al registro del mesh di servizi. I servizi che non sono 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 si basano 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 in modo che ascolti 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 di 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 di server). Infine, devi indicare alla voce di servizio l'acquisizione
del 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 o 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 del servizio. Per il protocollo, devi specificare TLS, perché questa connessione fornisce comunicazioni TLS basate 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 di servizio devono essere basate su voci DNS o di indirizzi IP esistenti, il che significa che il nome DNS dovrebbe essere già risolvibile da un server DNS. Ad esempio, puoi utilizzare un servizio DNS principale all'interno di Kubernetes e aggiungere voci che non sono già presenti in kube-dns. Non puoi utilizzare la voce di servizio per creare una voce DNS.
Servizio virtuale
Il servizio virtuale è una definizione utilizzata per influenzare i pattern di routing del traffico. Puoi utilizzare il servizio virtuale per assicurarti che le chiamate dal client MySQL alla voce di servizio vengano instradate al gateway in uscita. Pertanto, puoi configurare un servizio virtuale per instradare il traffico in base a fattori molto diversi. In un caso d'uso di L7, questi fattori vanno oltre il routing del traffico. Ad esempio, puoi indicare al servizio virtuale come reagire se un target non è raggiungibile. Questo esempio utilizza un sottoinsieme di questa funzionalità per instradare il traffico corrispondente solo al gateway in uscita per ulteriori elaborazioni.
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 inoltre 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 contenente 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 viene 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 viene 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 di 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 di certificati nel gateway affinché la comunicazione mTLS funzioni.
Regole della 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 è la 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 riportata di seguito è un esempio di regola per la 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 mesh interna del traffico, utilizzando la modalità ISTIO_MUTUAL (utilizzando il nome di dominio completo del gateway in uscita). Nello snippet di codice definisci un elemento subset, che viene utilizzato 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 correttamente il campo tls poiché definisce il criterio di mesh interno (ISTIO_MUTUAL). Nel campo sni (Service Name Indication), aggiungi il nome di dominio completo del gateway in entrata dal cluster di server.
La seconda regola di destinazione cripta il traffico con i certificati CA radice 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 viene nuovamente impostato 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,
perché stai utilizzando i certificati CA radice personalizzati e la controparte, ovvero il gateway in entrata che utilizza tls MUTUAL, deve identificarsi utilizzando gli stessi certificati CA radice firmati. Utilizzando questa porta, il traffico può passare 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.
Riassumendo, il traffico ora svolge le seguenti operazioni:
- Viene emesso da MySQL in modo trasparente verso un nome di dominio completo esterno. Questo nome di dominio completo esiste nella registrazione mesh.
- È criptata mediante una regola di destinazione che utilizza i certificati mesh interni.
- Viene instradato al gateway da un servizio virtuale.
- Viene criptata utilizzando una CA radice personalizzata da una regola di destinazione (diversa dalla CA mesh utilizzata per i certificati mesh).
- Viene inoltrato attraverso il gateway in uscita in modalità mTLS.
L'interfaccia
In questo scenario, il lato server è più facile da configurare rispetto al lato client. Tutto ciò che serve è 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à. Il seguente esempio di snippet di codice applica patch alla 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 delle credenziali e lo invia al mesh, dove i certificati interni del mesh vengono utilizzati per ricriptare il traffico. Il seguente esempio di snippet di codice 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 viene utilizzato il gateway in entrata Istio standard nel campo selector. Utilizzando il campo servers, puoi impostare i valori di 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, devi creare una corrispondenza con 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 in uscita del cluster client (origine), 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 verificare di nuovo l'host del 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, che è 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 DB MySQL. Per il server DB MySQL, sembra 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 dal client al server, il che aiuta a proteggere la comunicazione client-server.
La prima volta che il traffico viene criptato o decriptato viene eseguito all'interno del mesh sul lato client con certificati che utilizzano la CA mesh.
La seconda volta che il traffico viene criptato quando si lascia il mesh dal gateway in uscita utilizzando 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. Se applichi questa configurazione, è possibile gestire questa parte separatamente e indipendentemente dai certificati interni del mesh e dall'applicazione stessa.
Grazie a questo passaggio aggiuntivo, questa configurazione consente anche di ruotare facilmente questi certificati regolarmente senza modificare la CA mesh dei rispettivi cluster Kubernetes.
Passaggi successivi
- Prova il tutorial sui 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. Dai un'occhiata al nostro Cloud Architecture Center.