I cluster Anthos su VMware (GKE on-prem) utilizzano certificati e chiavi private per autenticare e criptare le connessioni tra componenti di sistema nei cluster utente. Il cluster di amministrazione crea un nuovo set di autorità di certificazione (CA) per ogni cluster utente e utilizza i certificati CA per emettere certificati di fogli aggiuntivi aggiuntivi per i componenti di sistema. Il cluster di amministrazione gestisce la distribuzione dei certificati CA pubblici e le coppie di chiavi dei certificati foglia ai componenti di sistema per stabilire la comunicazione sicura.
La funzionalità di rotazione CA del cluster utente ti consente di attivare una rotazione dei certificati di sistema principali in un cluster utente. Durante una rotazione, il cluster di amministrazione sostituisce le CA principali del sistema per il cluster utente con le nuove CA generate e distribuisce i nuovi certificati CA pubblici e le coppie di chiavi dei certificati foglia ai componenti del sistema del cluster utente. La rotazione avviene in modo incrementale, così che i componenti del sistema possano continuare a comunicare durante la rotazione. Tuttavia, i carichi di lavoro e i nodi verranno riavviati durante la rotazione.
Per ogni cluster utente sono gestite tre CA di sistema dal cluster di amministrazione:
- La CA etcd protegge la comunicazione dal server API alle repliche etcd e consente anche il traffico tra le repliche etcd. Questa CA è autofirmata.
- La CA del cluster protegge la comunicazione tra il server API e tutti i client API Kubernetes interni (kubelet, controller, scheduler). Questa CA è autofirmata.
- La CA proxy anteriore protegge la comunicazione con API aggregate. Questa CA è autofirmata.
Potresti anche utilizzare un'autorità di certificazione dell'organizzazione per firmare il certificato configurato dall'opzione authentication.sni.
Questa CA e il certificato SNI vengono utilizzati per gestire l'API Kubernetes per i client esterni al cluster. Potrai gestire questa CA e generare manualmente il certificato SNI. Né questa CA né il certificato SNI sono interessati dalla funzionalità di rotazione della CA del cluster utente.
Limitazioni
- La funzionalità di rotazione delle CA dei cluster utente è supportata sui cluster Anthos sui cluster VMware versione 1.8 e successive.
- La funzionalità di rotazione delle CA dei cluster utente è limitata esclusivamente alle CA etcd, del cluster e del proxy anteriore indicate nella panoramica. Non esegue la rotazione della funzionalità CA di rotazione del cluster utente. Inoltre, è limitata ai certificati emessi automaticamente dai cluster Anthos su VMware. Non aggiorna i certificati emessi manualmente da un amministratore, anche se tali certificati sono firmati dalle autorità di certificazione del sistema.
- Una rotazione di CA deve riavviare più volte il server API, gli altri processi del piano di controllo e ogni nodo nel cluster. Ogni fase di una rotazione di CA comporta l'avanzamento simile a un upgrade del cluster. Il cluster utente rimane operativo durante una rotazione delle CA, ma puoi aspettarti che i carichi di lavoro vengano riavviati e ripianificati. Dovresti anche prevedere brevi periodi di inattività del piano di controllo quando non utilizzi una configurazione ad alta disponibilità.
- I file kubeconfig del cluster utente e i file di configurazione dell'autenticazione per la connessione ai cluster utente devono essere aggiornati manualmente e ridistribuiti dopo una rotazione della CA. Questo perché la rotazione di CA revoca necessariamente la vecchia CA, pertanto le credenziali non saranno più autenticate.
- Una volta avviata, la rotazione di una CA non può essere messa in pausa o rollback.
- A seconda delle dimensioni del cluster utente, il completamento di una rotazione di CA potrebbe richiedere molto tempo.
Come eseguire una rotazione di CA
Puoi avviare una rotazione di CA e visualizzare lo stato corrente della rotazione eseguendo i comandi gkectl riportati di seguito.
Ruota certificati CA
Per attivare una rotazione di CA, esegui questo comando.
gkectl update credentials certificate-authorities rotate \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Dove:
- USER_CONFIG_FILE è il percorso del file di configurazione del cluster utente del cluster utente per cui eseguire la rotazione.
- ADMIN_KUBECONFIG_FILE è il percorso del file kubeconfig per la connessione al cluster di amministrazione che gestisce il cluster utente.
Se la rotazione della CA è stata avviata, verrà visualizzato un messaggio simile al seguente:
successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation
Se è già in corso una rotazione di CA, verrà visualizzato un messaggio di errore simile al seguente:
Exit with error: admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads
Visualizza lo stato della rotazione CA
Per visualizzare lo stato di una rotazione CA, esegui il comando seguente. Questo comando riporta CAVersion, un numero intero che viene incrementato automaticamente dal sistema per differenziare le CA utilizzate prima e dopo ogni rotazione della CA, uno stato (True o False) che indica se la rotazione della CA è stata completata e il messaggio che descrive quale CAVersion è attualmente in uso da parte di ogni componente del sistema.
gkectl update credentials certificate-authorities status \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Se la rotazione della CA è già completata, verrà visualizzato un messaggio simile al seguente:
State of CARotation with CAVersion 2 is - status: True, reason: CARotationCompleted, message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.
Se la rotazione della CA è ancora in corso, verrà visualizzato un messaggio simile al seguente:
State of CARotation with CAVersion 2 is - status: False, reason: CARotationProgressed, message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.
Aggiornamento credenziali cluster utente
Al termine della rotazione di una CA, è necessario scaricare un nuovo file kubeconfig del cluster utente dal cluster di amministrazione per sostituire il vecchio kubeconfig utilizzato in precedenza per la connessione ai cluster utente. Questo perché la rotazione CA revoca la vecchia CA su cui si basava il vecchio file kubeconfig. Esegui il comando seguente dopo che la rotazione della CA è stata completata per scaricare il nuovo file kubeconfig:
kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Se altri file kubeconfig sono stati rilasciati manualmente ad altri utenti del cluster, devono essere aggiornati.
Aggiornamento file di configurazione autenticazione
Una volta completata la rotazione delle CA, i file di configurazione dell'autenticazione devono essere aggiornati e ridistribuiti. Segui le istruzioni collegate per aggiornare e ridistribuire questi file dopo la rotazione della CA:
Risoluzione dei problemi relativi alla rotazione di una CA
Il comando gkectl diagnose supporta il controllo dello stato previsto di una rotazione CA completata rispetto a un cluster utente. Per istruzioni su come eseguire la diagnostica gkectl su un cluster utente, consulta la sezione Diagnosi dei problemi del cluster.
Se hai problemi con una rotazione di CA, contatta l'Assistenza Google e fornisci il risultato di gkectl diagnose.