Attendibilità cluster

Questa pagina descrive il modello di attendibilità nei cluster di Google Kubernetes Engine (GKE), incluse la comunicazione all'interno dei cluster e la modalità di autenticazione delle richieste per componenti come i control plane.

Questo documento è rivolto agli specialisti della sicurezza che vogliono comprendere il modello di attendibilità del cluster di GKE. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Prima di leggere questa pagina, assicurati di conoscere quanto segue:

Comunicazione all'interno del cluster

GKE applica vari meccanismi di sicurezza al traffico tra i componenti del cluster, come segue:

  • Traffico tra il piano di controllo e i nodi: il piano di controllo comunica con un nodo per gestire i contenitori. 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 piano di controllo, ad esempio dal kubelet al server API, la richiesta viene autenticata e criptata utilizzando TLS reciproco (mTLS).

    Tutti i cluster appena creati e aggiornati utilizzano TLS 1.3 per la comunicazione tra il piano di controllo e i nodi. TLS 1.2 è la versione minima supportata per la comunicazione tra il piano di controllo e il nodo.

  • Traffico tra i nodi: i nodi sono VM di Compute Engine. Le connessioni tra i nodi all'interno della Google Cloud rete di produzione vengono autenticate e criptate. Per maggiori dettagli, consulta la sezione VM-to-VM del white paper sulla crittografia dei dati in transito.

  • Traffico tra 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 del livello di rete, consulta Google Cloud crittografia e autenticazione della rete virtuale.

    Puoi limitare il traffico da pod a pod con un NetworkPolicy e puoi criptare tutto il traffico da pod a 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 piano di controllo: il traffico tra i vari componenti in esecuzione sul piano di controllo viene autenticato e criptato utilizzando TLS. Il traffico non esce mai da una rete di proprietà di Google protetta da firewall.

Radice di attendibilità

GKE ha la seguente configurazione:

  • L'autorità di certificazione (CA) radice del cluster viene utilizzata per convalidare i certificati client del server API e dei kubelet. In altre parole, i piani di controllo e i nodi hanno la stessa radice di attendibilità. Qualsiasi kubelet all'interno del pool di nodi del cluster può richiedere un certificato da questa CA utilizzando l'API certificates.k8s.io inviando una richiesta di firma del certificato. La CA radice ha una durata limitata, come descritto nella sezione Durata della CA radice del cluster.
  • Nei cluster che eseguono istanze di database etcd sulle VM del control plane, viene utilizzata una CA peer etcd separata per ciascun cluster per stabilire la fiducia tra le istanze etcd.
  • In tutti i cluster GKE viene utilizzata un'autorità di certificazione API etcd separata per stabilire la fiducia tra il server API Kubernetes e l'API etcd.

Server API e kubelet

Il server API e i kubelet si basano sulla CA radice del cluster per la attendibilità. In GKE, il certificato dell'API del piano di controllo è firmato dalla CA radice del cluster. Ogni cluster esegue la propria CA, pertanto se la CA di un cluster viene compromessa, non viene interessata nessuna altra CA di cluster.

Le chiavi radice di questa CA, che non sono esportabili, vengono gestite da un servizio interno. Questo servizio accetta richieste di firma del certificato, incluse quelle dei kubelet in ogni cluster GKE. Anche se il server API di un cluster fosse compromesso, la CA non lo sarebbe, quindi nessun altro cluster sarebbe interessato.

A ogni nodo del cluster viene iniettato un Secret condiviso al momento della creazione, che può essere utilizzato per inviare richieste di firma del certificato all'autorità di certificazione radice del cluster e ottenere i certificati client kubelet. Questi certificati vengono poi utilizzati dal kubelet per autenticare le sue richieste al server API. Questo segreto condiviso è raggiungibile dai pod sul nodo, a meno che non abiliti i nodi GKE schermati o la federazione delle identità per i carichi di lavoro per GKE.

Durata dell'autorità di certificazione radice del cluster

L'autorità di certificazione radice del cluster ha una durata limitata, dopodiché tutti i certificati firmati dall'autorità di certificazione scaduta non sono validi. Controlla la data di scadenza approssimativa della CA del tuo cluster seguendo le istruzioni riportate in Verificare 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 provare a impedire la formazione di cluster non recuperabili:

  • Il cluster entra in uno stato DEGRADED sette giorni prima della scadenza della CA

  • GKE tenta una rotazione automatica delle credenziali 30 giorni prima della scadenza dell'autorità di certificazione. Questa rotazione automatica ignora le finestre di manutenzione e potrebbe causare interruzioni durante la reimpostazione dei nodi da parte di GKE per utilizzare nuove credenziali. I client esterni, come kubectl negli ambienti locali, non funzioneranno finché non li aggiorni in modo che utilizzino le nuove credenziali.

Per scoprire come eseguire una rotazione, consulta Rotare le credenziali del cluster.

Spazio di archiviazione dello stato del cluster

I cluster GKE archiviano lo stato degli oggetti API di Kubernetes come coppie chiave-valore in un database. Il server API Kubernetes nel tuo piano di controllo 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 in esecuzione sulle VM del piano di controllo.
  • Spanner: il cluster utilizza un database Spanner che viene eseguito al di fuori delle VM del piano di controllo.

Indipendentemente dalla tecnologia di database utilizzata da un cluster, ogni cluster GKE esegue l'API etcd nel piano di controllo. 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 verso e da endpoint API etcd. Un'API CA etcd viene eseguita in ogni cluster GKE.
  • CA peer etcd: utilizzata per firmare i certificati per il traffico tra le istanze del database etcd nel piano di controllo. Una CA peer etcd viene eseguita in qualsiasi cluster che utilizza i database etcd. I cluster che utilizzano i database Spanner non utilizzano la CA peer etcd.

Le chiavi di root per la CA dell'API etcd vengono distribuite ai metadati di ogni istanza Compute Engine su cui viene eseguito il piano di controllo. Il CA dell'API etcd non è condiviso tra i cluster.

I certificati CA etcd sono validi per cinque anni. GKE gira automaticamente questi certificati prima che scadano.

Rotazione dei certificati

Per ruotare tutti i certificati del server API e del kubelet del cluster, esegui una rotazione delle credenziali. Non puoi attivare una rotazione dei certificati etcd; questa operazione viene gestita per te in GKE.

Passaggi successivi