Attendibilità cluster

Questo documento riguarda il modello di attendibilità nei cluster Google Kubernetes Engine (GKE), inclusa la comunicazione all'interno dei cluster e la modalità di autenticazione delle richieste per componenti come i piani di controllo. Questo documento presuppone che tu conosca le seguenti informazioni:

Questo documento è rivolto agli specialisti della sicurezza che vogliono comprendere il modello di attendibilità dei cluster di GKE. Per saperne 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.

Comunicazione intracluster

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 la gestione dei container. 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 vengono 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 il piano di controllo e i nodi. TLS 1.2 è la versione minima supportata per la comunicazione tra il piano di controllo e i nodi.

  • Traffico tra i nodi: i nodi sono VM di Compute Engine. Le connessioni tra i nodi all'interno della rete di produzione vengono autenticate e criptate. Google Cloud Per i dettagli, consulta la sezione Da VM a VM di 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 viene criptato per impostazione predefinita. Per i dettagli sulla crittografia a 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 altro metodo 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 radice (CA) 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.
  • Nei cluster che eseguono istanze del database etcd sulle VM del piano di controllo, 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 basano sulla CA radice del cluster per l'attendibilità. In GKE, il certificato API del piano di controllo è firmato dalla CA radice del cluster. Ogni cluster esegue la propria CA, in modo che se la CA di un cluster viene compromessa, non venga interessata nessun'altra CA del cluster.

Un servizio interno gestisce le chiavi radice di 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 in un cluster è stato compromesso, la CA non lo sarà, quindi nessun altro cluster verrà interessato.

A ogni nodo del cluster viene inserito un secret condiviso al momento della creazione, che può utilizzare per inviare richieste di firma del certificato alla CA radice del cluster e ottenere certificati client kubelet. Questi certificati vengono quindi utilizzati dal kubelet per autenticare le 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 radice del cluster ha una durata limitata, dopodiché tutti i certificati firmati dalla CA scaduta non sono validi. Controlla la data di scadenza approssimativa della CA del cluster seguendo le istruzioni riportate in Controllare 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 impedire la creazione 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 della CA. Questa rotazione automatica ignora le finestre di manutenzione e potrebbe causare interruzioni perché GKE ricrea i nodi per utilizzare nuove credenziali. I client esterni, come kubectl negli ambienti locali, non funzioneranno finché non li aggiorni per utilizzare le nuove credenziali.

Per scoprire come eseguire una rotazione, consulta Ruotare 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 in esecuzione sulle VM del piano di controllo.
  • Spanner: il cluster utilizza un database Spanner in esecuzione all'esterno delle VM del piano di controllo.

Indipendentemente dalla tecnologia di database utilizzata da un cluster, ogni cluster GKE gestisce 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 da e verso gli endpoint API etcd. Una CA API etcd viene eseguita in ogni cluster GKE.
  • CA peer etcd: utilizzata per firmare i certificati per il traffico tra le istanze del database etcd sul 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 radice per la CA API etcd vengono distribuite ai metadati di ogni istanza di Compute Engine su cui è in esecuzione il piano di controllo. La CA 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. Il certificato verrà ruotato automaticamente 6 mesi prima della scadenza.

Rotazione dei certificati

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

Passaggi successivi