Rotazione dei certificati CA del cluster di amministrazione

Google Distributed Cloud utilizza certificati e chiavi private per autenticare la comunicazione tra i componenti di sistema Kubernetes in un cluster amministrativo. Quando crei un cluster di amministrazione, vengono creati nuovi certificati delle autorità di certificazione (CA) e questi certificati radice vengono utilizzati per emettere certificati secondari aggiuntivi per i componenti di sistema di Kubernetes.

Questa guida si applica solo alla rotazione dei certificati CA del cluster di amministrazione. Per i cluster utente, consulta Rotazione dei certificati CA dei cluster utente.

Esistono tre certificati CA utilizzati dal sistema Kubernetes in un cluster amministrativo:

• Il certificato CA di etcd protegge la comunicazione dal server API Kubernetes alle repliche di etcd e anche la comunicazione tra le repliche di etcd. Questo certificato è autofirmato.

• Il certificato CA del cluster protegge la comunicazione tra il server API Kubernetes e tutti i client API Kubernetes interni, ad esempio kubelet, il gestore dei controller e lo scheduler. Questo certificato è autofirmato.

• Il certificato CA del proxy anteriore protegge la comunicazione con le API aggregate. Questo certificato è autofirmato.

Puoi utilizzare gkectl per attivare una rotazione dei certificati. Durante una rotazione, gkectl sostituisce i certificati CA di sistema di base per il cluster amministrativo con certificati appena generati. Poi distribuisce i nuovi certificati CA, i certificati a foglia e le chiavi private ai componenti di sistema del cluster amministrativo. La rotazione avviene in modo incrementale, in modo che i componenti di sistema possano continuare a comunicare durante la rotazione. Tieni presente, tuttavia, che i carichi di lavoro e i nodi vengono riavviati durante la rotazione.

Senza la rotazione, i certificati CA e del piano di controllo scadranno cinque anni dopo la data di creazione del cluster. I certificati del piano di controllo vengono ruotati automaticamente durante un upgrade del cluster, ma le CA non vengono ruotate automaticamente. Ciò significa che una rotazione della CA deve essere eseguita almeno una volta ogni cinque anni, oltre agli upgrade della versione regolari.

Limitazioni

• Tieni presente la seguente limitazione dei cluster avanzati:

  • Versione 1.31: la rotazione della CA non è supportata nei cluster avanzati.
  • Versione 1.32 e successive: la rotazione della CA è supportata nei cluster avanzati, ma esistono alcune piccole differenze, indicate ove applicabili, in questo documento.

• La rotazione dei certificati CA è limitata ai certificati etcd, cluster e front-proxy precedentemente menzionati.

• La rotazione dei certificati CA è limitata ai certificati emessi automaticamente da Google Distributed Cloud. Non aggiorna i certificati emessi manualmente da un amministratore, anche se sono firmati dalle CA di sistema.

• La rotazione dei certificati CA riavvia più volte il server API Kubernetes, altri processi di controllo e ogni nodo del cluster di amministrazione. Ogni fase di una rotazione procede in modo simile a un upgrade del cluster. Sebbene il cluster di amministrazione e i cluster utente gestiti dal cluster di amministrazione rimangano operativi durante la rotazione dei certificati, è normale che i workload nel cluster di amministrazione vengano riavviati e riprogrammati. Dovresti anche aspettarti brevi periodi di inattività per il control plane del cluster di amministrazione e per il control plane del cluster utente.

• Devi aggiornare il file kubeconfig del cluster di amministrazione durante una rotazione dei certificati e di nuovo al termine della rotazione. Questo accade perché il vecchio certificato del cluster viene revocato e le credenziali nel file kubeconfig non funzioneranno più.

• Una volta avviata, la rotazione dei certificati CA non può essere annullata.

• La rotazione dei certificati CA potrebbe richiedere molto tempo, a seconda delle dimensioni del cluster.

• Se viene interrotta, la procedura di rotazione dei certificati può essere ripresa eseguendo di nuovo lo stesso comando. Tuttavia, devi assicurarti che sia in esecuzione un solo comando di rotazione alla volta.

Avvia la rotazione

Per avviare la rotazione dei certificati, esegui il seguente comando:

gkectl update credentials certificate-authorities rotate \
    --admin-cluster \
    --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Sostituisci quanto segue:

• ADMIN_CLUSTER_CONFIG: il percorso del file di configurazione del cluster di amministrazione

• ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione

Il comportamento del comando varia a seconda che il cluster avanzato sia attivo:

gkectl update credentials certificate-authorities update-kubeconfig \
  --admin-cluster \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gkectl update credentials certificate-authorities rotate \
  --admin-cluster \
  --complete \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gkectl update credentials certificate-authorities update-kubeconfig \
  --admin-cluster \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Beginning CA rotation with generated CA
...
Successfully rotated CA for admin cluster. The kubeconfig file
"/home/ubuntu/kubeconfig" has been updated.
Done rotating certificate-authorities

Distribuisci il nuovo file kubeconfig

Distribuisci il nuovo file kubeconfig del cluster di amministrazione a tutti gli utenti del cluster.