Google Distributed Cloud utilizza certificati e chiavi private per l'autenticazione comunicazione tra i componenti di sistema di Kubernetes in un cluster di amministrazione. Quando creare un cluster di amministrazione, vengono creati nuovi certificati delle autorità di certificazione (CA) e vengono utilizzati per emettere certificati foglia aggiuntivi per componenti di sistema di Kubernetes.
Questa guida si applica solo alla rotazione dei certificati CA del cluster di amministrazione. Per per i cluster utente, Rotazione dei certificati CA del cluster utente.
Esistono tre certificati CA utilizzati dal sistema Kubernetes in un cluster:
Il certificato CA etcd protegge le comunicazioni dal server API Kubernetes alle repliche etcd e anche alla comunicazione tra le repliche etcd. Questo è autofirmato.
Il certificato CA del cluster protegge le comunicazioni tra l'API Kubernetes un server web e tutti i client API interni di Kubernetes, ad esempio kubelet, il gestore del controller e lo scheduler. Questo certificato è autofirmato.
Il certificato CA del proxy frontale protegge le comunicazioni con API aggregate. Questo certificato è autofirmato.
Puoi utilizzare gkectl per attivare una rotazione dei certificati. Durante una rotazione,
gkectl sostituisce i certificati CA del sistema principali per
cluster di amministrazione con i certificati appena generati. Quindi distribuisce il nuovo
Certificati CA, certificati foglia e chiavi private per il sistema del cluster di amministrazione
componenti. La rotazione avviene in modo incrementale, in modo che i componenti del sistema
continuano a comunicare durante la rotazione. Tuttavia, tieni presente che i carichi di lavoro
i nodi vengono riavviati durante la rotazione.
Senza la rotazione, i certificati CA e i certificati del piano di controllo scadranno cinque anni dalla data di creazione del cluster. I certificati del piano di controllo vengono ruotati automaticamente durante l'upgrade di un cluster, ma non ruotato automaticamente. Ciò significa che una rotazione CA deve essere una volta ogni cinque anni, oltre ai normali upgrade della versione.
Limitazioni
Rotazione del certificato CA limitata a etcd, cluster e front-proxy di cui sopra.
La rotazione dei certificati CA è limitata ai certificati emessi automaticamente da Google Distributed Cloud. Non aggiorna i certificati emessi manualmente da un dell'amministratore, anche se tali certificati sono firmati dalle CA del sistema.
La rotazione del certificato CA riavvia il server API Kubernetes, dei processi del piano di controllo e ogni nodo nel cluster di amministrazione viene ripetuto più volte. Ogni fase di una rotazione procede in modo simile all'upgrade di un cluster. Mentre il cluster di amministrazione e i cluster utente gestiti dal cluster di amministrazione rimangono operativo durante la rotazione dei certificati, dovresti aspettarti che i carichi di lavoro nel cluster di amministrazione verrà riavviato e ripianificato. Dovresti anche aspettarti brevi periodi di inattività per il piano di controllo del cluster di amministrazione e il cluster utente dal piano di controllo.
Devi aggiornare il file kubeconfig del cluster di amministrazione durante una la rotazione dei certificati e di nuovo al termine della rotazione. Questo perché viene revocato il certificato del cluster precedente e le credenziali in kubeconfig non funzionerà più.
Una volta avviata, la rotazione di un certificato CA non può essere annullata.
Il completamento di una rotazione di un certificato CA può richiedere molto tempo, a seconda in base alle dimensioni del cluster.
La procedura di rotazione dei certificati può essere ripresa eseguendo di nuovo lo stesso se viene interrotto. Tuttavia, devi assicurarti che sia presente un solo di rotazione in esecuzione alla volta.
Avvia la rotazione
Per avviare la rotazione dei certificati, esegui il comando seguente. Esegue la prima metà della rotazione e si ferma in un punto di pausa.
Avvia la rotazione:
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Sostituisci quanto segue:
ADMIN_CLUSTER_CONFIG: il percorso della configurazione del cluster di amministrazione file
ADMIN_CLUSTER_KUBECONFIG: il percorso di kubeconfig del cluster di amministrazione file
Se il comando viene interrotto, riprendilo eseguendo lo stesso comando.
Aggiorna il file kubeconfig
Quando il comando precedente viene messo in pausa, aggiorna il file kubeconfig per l'amministratore in un cluster Kubernetes. Vengono inseriti un nuovo certificato client e un nuovo certificato CA nella kubeconfig. Il certificato client precedente viene rimosso dal file kubeconfig, mentre il certificato CA precedente rimane nel file kubeconfig.
gkectl update credentials certificate-authorities update-kubeconfig \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Continua la rotazione
Esegui questo comando per eseguire la seconda metà della procedura. La
il comando non procederà finché gkectl non verifica che il file kubeconfig aggiornato
si trova nella directory attuale.
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--complete \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Se il comando viene interrotto, riprendilo eseguendo lo stesso comando.
Al termine della rotazione, viene segnalata la versione della CA corrente.
Aggiorna di nuovo il file kubeconfig
Al termine della seconda metà della rotazione, aggiorna il file kubeconfig di nuovo. Questa operazione rimuove il certificato CA precedente dal file kubeconfig.
gkectl update credentials certificate-authorities update-kubeconfig \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Distribuisci il nuovo file kubeconfig
Distribuisci il file kubeconfig del nuovo cluster di amministrazione a tutti gli utenti del cluster.