GKE su VMware utilizza certificati e chiavi private per autenticare la comunicazione tra i componenti di sistema di Kubernetes in un cluster di amministrazione. Quando crei un cluster di amministrazione, vengono creati nuovi certificati dell'autorità di certificazione (CA) che vengono utilizzati per emettere certificati foglia 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 del cluster utente.
Esistono tre certificati CA utilizzati dal sistema Kubernetes in un cluster di amministrazione:
Il certificato CA etcd protegge la comunicazione tra il server API Kubernetes e le repliche etcd, nonché la comunicazione tra le repliche etcd. Questo certificato è autofirmato.
Il certificato CA del cluster protegge le comunicazioni tra il server API Kubernetes e tutti i client API Kubernetes interni, ad esempio kubelet, gestore del controller e scheduler. Questo certificato è autofirmato.
Il certificato CA del proxy frontale protegge la comunicazione con le API aggregate. Questo certificato è autofirmato.
Puoi utilizzare gkectl per attivare una rotazione del certificato. Durante una rotazione, gkectl sostituisce i certificati CA del sistema principali per il cluster di amministrazione con certificati appena generati. Poi distribuisce i nuovi certificati CA, i certificati foglia e le chiavi private ai componenti del sistema del cluster di amministrazione. La rotazione avviene in modo incrementale, in modo che i componenti di sistema possano
continuare a comunicare durante la rotazione. Tuttavia, tieni presente che i carichi di lavoro e i nodi
vengono riavviati durante la rotazione.
Senza rotazione, i certificati CA e i certificati del piano di controllo scadranno cinque anni dopo la data di creazione del cluster. I certificati del piano di controllo vengono ruotati automaticamente durante l'upgrade di un 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 ai normali upgrade della versione.
Limitazioni
Rotazione del certificato CA limitata ai certificati etcd, cluster e front-proxy menzionati in precedenza.
La rotazione dei certificati CA è limitata ai certificati emessi automaticamente da GKE su VMware. Non aggiorna i certificati emessi manualmente da un amministratore, anche se sono firmati dalle CA del sistema.
La rotazione del certificato CA riavvia più volte il server API Kubernetes, gli altri processi del piano di controllo e ogni nodo nel cluster di amministrazione. Ogni fase di una rotazione procede in modo simile all'upgrade di un cluster. Anche se il cluster di amministrazione e i cluster utente gestiti dal cluster di amministrazione rimangono operativi durante una rotazione dei certificati, è normale che i carichi di lavoro nel cluster di amministrazione vengano riavviati e ripianificati. Dovresti inoltre prevedere brevi periodi di inattività per il piano di controllo del cluster di amministrazione e quello del cluster utente.
Devi aggiornare il file kubeconfig del cluster di amministrazione durante una rotazione del certificato e di nuovo al termine della rotazione. Questo perché il vecchio certificato del cluster è stato revocato e le credenziali nel file kubeconfig non funzioneranno più.
Una volta avviata, non è possibile eseguire il rollback di una rotazione del certificato CA.
Il completamento di una rotazione di un certificato CA potrebbe richiedere molto tempo, a seconda delle dimensioni del cluster.
Il processo di rotazione del certificato può essere ripreso eseguendo nuovamente lo stesso comando in caso di interruzione. Tuttavia, devi assicurarti che sia in esecuzione un solo comando di rotazione alla volta.
Avvia la rotazione
Per avviare la rotazione del certificato, esegui questo comando. 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 del file di configurazione del cluster di amministrazione
ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione
Se il comando viene interrotto, ripristinalo eseguendo lo stesso comando.
Aggiorna il file kubeconfig
Quando il comando precedente viene messo in pausa, aggiorna il file kubeconfig per il cluster di amministrazione. Nel file kubeconfig vengono inseriti un nuovo certificato client e un nuovo certificato CA. Il vecchio certificato client 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. Il comando non procederà finché gkectl non avrà verificato 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, ripristinalo eseguendo lo stesso comando.
Al termine della rotazione, viene riportata la versione corrente della CA.
Aggiorna di nuovo il file kubeconfig
Dopo il completamento della seconda metà della rotazione, aggiorna nuovamente il file kubeconfig. Il vecchio certificato CA viene rimosso 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.