Attendibilità cluster

Questa pagina descrive la fiducia nei cluster Google Kubernetes Engine (GKE), incluso come i piani di controllo e i nodi autenticano le richieste.

Comunicazione all'interno del cluster

In un cluster esistono molte connessioni per la comunicazione tra i componenti Kubernetes.

Control plane to node

Il piano di controllo comunica con un nodo per gestire i contenitori. Quando il piano di controllo invia una richiesta, ad esempio kubectl logs, ai nodi, la richiesta viene inviata tramite un tunnel proxy Konnectivity. Le richieste inviate dal piano di controllo sono protette con TLS, che fornisce autenticazione, integrità e crittografia. Quando un node invia una richiesta al piano di controllo, ad esempio dal kubelet al server API, la richiesta viene autenticata e criptata utilizzando TLS reciproco.

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 control plane e il nodo.

Da nodo a nodo

I nodi sono VM Compute Engine per le quali le connessioni all'interno della rete di produzione di Google Cloud sono autenticate e criptate. Per maggiori dettagli, consulta la sezione VM-to-VM del white paper sulla crittografia dei dati in transito.

Da pod a 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 informazioni dettagliate sulla crittografia a livello di rete, consulta Crittografia e autenticazione della rete virtuale di Google Cloud.

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.

da etcd a etcd

Un'istanza di etcd può comunicare con un'altra istanza di etcd per mantenere aggiornato lo stato. Quando un'istanza di etcd invia una richiesta a un'altra istanza, la richiesta viene autenticata e criptata utilizzando TLS reciproco. Il traffico non esce mai da una rete di proprietà di GKE protetta da firewall.

Control plane to etcd

Questa comunicazione è criptata utilizzando TLS reciproco.

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 a 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.
  • Per convalidare i certificati di etcd viene utilizzata una CA etcd separata per ciascun cluster.

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 dall'autorità di certificazione radice del cluster. Ogni cluster esegue la propria CA, pertanto se la CA di un cluster viene compromessa, non viene interessata nessuna altra CA del 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, dopo la quale 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.

etcd

In GKE, etcd si basa su una CA etcd separata per ciascun cluster per la fiducia.

Le chiavi principali per la CA etcd vengono distribuite ai metadati di ogni macchina virtuale (VM) su cui viene eseguito il piano di controllo. Qualsiasi codice in esecuzione sulle VM del control plane o con accesso ai metadati di calcolo per queste VM può firmare i certificati come questa CA. Anche se la CA di etcd in un cluster fosse compromessa, la CA non viene condivisa tra i cluster, pertanto nessun altro cluster sarebbe interessato.

I certificati etcd sono validi per cinque anni.

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