Questo documento descrive il modello di attendibilità nei cluster Google Kubernetes Engine (GKE), tra cui la comunicazione all'interno dei cluster e il modo in cui le richieste vengono autenticate per componenti come i control plane. Questo documento presuppone che tu conosca quanto segue:
Questo documento è rivolto agli esperti di sicurezza che vogliono comprendere il modello di attendibilità dei cluster di GKE. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.
Comunicazione intracluster
GKE applica vari meccanismi di sicurezza al traffico tra i componenti del cluster, come segue:
Traffico tra il control plane e i nodi: il control plane comunica con un nodo per la gestione dei container. Quando il control plane invia una richiesta (ad esempio
kubectl logs) ai nodi, la richiesta viene inviata tramite un tunnel proxy Konnectivity. Le richieste inviate dal control plane sono autenticate e protette da TLS. Quando un nodo invia una richiesta al control plane, ad esempio dal kubelet al server API, la richiesta viene autenticata e criptata utilizzando mutual TLS (mTLS).Tutti i cluster appena creati e aggiornati utilizzano TLS 1.3 per la comunicazione tra control plane e nodi. TLS 1.2 è la versione minima supportata per la comunicazione tra control plane e nodi.
Traffico tra nodi: i nodi sono VM di Compute Engine. Le connessioni tra i nodi all'interno della rete di produzione Google Cloud sono autenticate e criptate. Per maggiori dettagli, consulta la sezione Da VM a VM del white paper sulla crittografia dei dati in transito.
Traffico tra i pod: quando un pod invia una richiesta a un altro pod, il traffico non viene autenticato per impostazione predefinita. GKE cripta il traffico tra i pod su nodi diversi a livello di rete. Il traffico tra i pod sullo stesso nodo non è criptato per impostazione predefinita. Per maggiori dettagli sulla crittografia a livello di rete, consulta Crittografia e autenticazione della rete virtualeGoogle Cloud .
Puoi limitare il traffico tra pod con un NetworkPolicy e puoi criptare tutto il traffico tra pod, incluso il traffico sullo stesso nodo, utilizzando un mesh di servizi come Cloud Service Mesh o un metodo diverso di crittografia a livello di applicazione.
Traffico tra i componenti del control plane: il traffico tra i vari componenti eseguiti sul control plane viene autenticato e criptato utilizzando TLS. Il traffico non lascia mai una rete di proprietà di Google protetta da firewall.
Root of trust
GKE ha la seguente configurazione:
- L'autorità di certificazione radice del cluster viene utilizzata per convalidare i certificati client del server API e dei kubelet. In altre parole, i control plane e i nodi hanno la stessa radice di attendibilità. Qualsiasi kubelet all'interno del pool di nodi del cluster può richiedere un certificato a questa CA utilizzando l'API
certificates.k8s.io, inviando una richiesta di firma del certificato. La CA principale ha una durata limitata, come descritto nella sezione Durata della CA principale del cluster. - Nei cluster che eseguono istanze di database etcd sulle VM del control plane, viene utilizzata una CA peer etcd separata per cluster per stabilire l'attendibilità tra le istanze etcd.
- In tutti i cluster GKE, viene utilizzata una CA API etcd separata per stabilire l'attendibilità tra il server API Kubernetes e l'API etcd.
Server API e kubelet
Il server API e i kubelet si affidano alla CA root del cluster per l'attendibilità. In GKE, il certificato API del control plane è firmato dalla CA root del cluster. Ogni cluster esegue la propria CA, in modo che se la CA di un cluster viene compromessa, la CA di nessun altro cluster viene interessata.
Un servizio interno gestisce le chiavi root per questa CA, che non sono esportabili. Questo servizio accetta le richieste di firma del certificato, incluse quelle dei kubelet in ogni cluster GKE. Anche se il server API di un cluster venisse compromesso, la CA non lo sarebbe, quindi nessun altro cluster verrebbe interessato.
Al momento della creazione, in ogni nodo del cluster viene inserito un secret condiviso, che può essere utilizzato per inviare richieste di firma del certificato alla CA radice del cluster e ottenere certificati client kubelet. Questi certificati vengono poi utilizzati dal kubelet per autenticare le sue richieste al server API. Questo secret condiviso è raggiungibile dai pod sul nodo, a meno che non abiliti Shielded GKE Nodes o Workload Identity Federation for GKE.
Durata della CA radice del cluster
La CA root del cluster ha una durata limitata, dopo la quale i certificati firmati dalla CA scaduta non sono validi. Controlla la data di scadenza approssimativa della CA del tuo cluster seguendo le istruzioni riportate in Controlla la durata delle credenziali.
Devi ruotare manualmente le credenziali prima della scadenza della CA radice esistente. Se la CA scade e non ruoti le credenziali, il cluster potrebbe entrare in uno stato non recuperabile. GKE dispone dei seguenti meccanismi per cercare di prevenire i cluster non recuperabili:
- Il cluster entra in uno stato
DEGRADEDsette giorni prima della scadenza della CA GKE tenta una rotazione automatica delle credenziali 30 giorni prima della scadenza della CA. Questa rotazione automatica ignora i periodi di manutenzione e potrebbe causare interruzioni, poiché GKE ricrea i nodi per utilizzare le nuove credenziali. I client esterni, come kubectl negli ambienti locali, non funzioneranno finché non li aggiornerai in modo che utilizzino le nuove credenziali.
Per scoprire come eseguire una rotazione, consulta Ruota le credenziali del cluster.
Archiviazione dello stato del cluster
I cluster GKE archiviano lo stato degli oggetti API Kubernetes come coppie chiave-valore in un database. Il server API Kubernetes nel control plane interagisce con questo database utilizzando l'API etcd. GKE utilizza una delle seguenti tecnologie per eseguire il database dello stato del cluster:
- etcd: il cluster utilizza istanze etcd eseguite sulle VM del control plane.
- Spanner: il cluster utilizza un database Spanner che viene eseguito al di fuori delle VM del control plane.
Indipendentemente dalla tecnologia di database utilizzata da un cluster, ogni cluster GKE gestisce l'API etcd nel control plane. Per criptare il traffico che coinvolge il database dello stato del cluster, GKE utilizza una o entrambe le seguenti CA per cluster:
- CA API etcd: utilizzata per firmare i certificati per il traffico da e verso gli endpoint API etcd. In ogni cluster GKE viene eseguita una CA API etcd.
- CA peer etcd: utilizzata per firmare i certificati per il traffico tra le istanze del database etcd sul control plane. Una CA peer etcd viene eseguita in qualsiasi cluster che utilizza database etcd. I cluster che utilizzano database Spanner non utilizzano la CA peer etcd.
Le chiavi root per la CA dell'API etcd vengono distribuite ai metadati di ogni istanza Compute Engine su cui viene eseguito il control plane. La CA dell'API etcd non è condivisa tra i cluster.
La validità del certificato CA etcd dipende dalla data di creazione del cluster, come segue:
- Per i cluster creati prima di ottobre 2021, il certificato è valido per 5 anni.
- Per i cluster creati dopo ottobre 2021, il certificato è valido per 30 anni. Indipendentemente dalla data di creazione del cluster, il nuovo certificato CA etcd creato durante una rotazione dei certificati è valido per 30 anni. La rotazione del certificato verrà eseguita automaticamente 6 mesi prima della scadenza.
Rotazione dei certificati
Per ruotare tutti i certificati del server API e di kubelet del cluster, esegui una rotazione delle credenziali. Non è possibile attivare una rotazione dei certificati etcd; questa operazione viene gestita per te in GKE.