Google Distributed Cloud utilizza certificati e chiavi private per autenticare e criptare le connessioni tra i componenti di sistema nei cluster utente. Il cluster di amministrazione crea un nuovo insieme di autorità di certificazione (CA) per ogni cluster utente e utilizza i certificati CA per emettere certificati foglia aggiuntivi per i componenti di sistema. Il cluster di amministrazione gestisce la distribuzione delle coppie di chiavi di certificati CA pubblici e certificati foglia ai componenti di sistema per stabilire la loro comunicazione sicura.
La funzionalità di rotazione della CA del cluster utente consente di attivare la rotazione dei certificati di sistema principali in un cluster utente. Durante una rotazione, il cluster di amministrazione sostituisce le CA di sistema principali per il cluster utente con CA appena generate e distribuisce le nuove coppie di chiavi di certificati CA pubblici e certificati foglia ai componenti di sistema del cluster utente. 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.
Esistono tre CA di sistema gestite dal cluster di amministrazione per ogni cluster utente:
- La CA etcd protegge la comunicazione dal server API alle repliche etcd e 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 del proxy front-end protegge la comunicazione con le API aggregate. Questa CA è autofirmata.
Inoltre, potresti utilizzare una CA dell'organizzazione per
firmare il certificato configurato dall'opzione authentication.sni.
Questa CA e il certificato SNI vengono utilizzati per pubblicare l'API Kubernetes ai client esterni al cluster. Gestisci questa CA e generi manualmente il certificato SNI. Né questa CA né il certificato SNI sono interessati dalla funzionalità di rotazione della CA del cluster utente.
Limitazioni
Tieni presente la seguente limitazione con i 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, se applicabili, in questo documento.
La rotazione dei certificati CA è limitata alle CA etcd, cluster e proxy front-end menzionate in precedenza.
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 questi certificati sono firmati dalle CA di sistema.
Una rotazione della CA riavvia più volte il server API, altri processi del piano di controllo e ogni nodo del cluster. Ogni fase di una rotazione della CA procede in modo simile a un upgrade del cluster. Sebbene il cluster utente rimanga operativo durante una rotazione della CA, dovresti aspettarti che i carichi di lavoro vengano riavviati e ripianificati. Dovresti anche aspettarti brevi periodi di inattività del piano di controllo se il cluster utente non ha un piano di controllo ad alta disponibilità.
Dopo una rotazione della CA, devi aggiornare il file kubeconfig del cluster utente e i file di configurazione dell'autenticazione. Questo perché il vecchio certificato del cluster viene revocato e le credenziali nel file kubeconfig non funzionano più.
Una volta avviata, una rotazione della CA non può essere messa in pausa o eseguita il rollback.
Il completamento di una rotazione della CA potrebbe richiedere un tempo considerevole, a seconda delle dimensioni del cluster utente.
Eseguire una rotazione della CA
Avvia la rotazione:
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGSostituisci quanto segue:
USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente
ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione
Il comportamento del comando varia a seconda che il cluster avanzato sia abilitato o meno:
Non abilitato
Se il cluster avanzato non è abilitato nel cluster, il comando è asincrono, avvia la rotazione della CA e poi si chiude. Non è necessario monitorare l'output del comando per l'intera durata della rotazione della CA. In alternativa, puoi controllare periodicamente l'avanzamento eseguendo il comando gkectl update credentials certificate-authorities status.
Se la rotazione della CA viene avviata correttamente, viene 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 della CA, viene 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
Per visualizzare lo stato della rotazione:
gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Il comando precedente segnala CAVersion, che è un numero intero che il sistema incrementa automaticamente per distinguere le CA utilizzate prima e dopo una rotazione. Il comando segnala anche uno stato (True o False) che indica se la rotazione della CA è completa e un messaggio che descrive quale CAVersion è attualmente in uso da ogni componente del sistema.
Se la rotazione della CA è già stata completata, viene 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, viene 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.
Aggiornare le credenziali del cluster utente
Nei cluster in cui non è abilitato il cluster avanzato, devi ottenere un nuovo file kubeconfig del cluster utente dal cluster di amministrazione. Questo perché la rotazione della CA revoca la CA su cui si basava il vecchio file kubeconfig.
Ottieni un nuovo file kubeconfig:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Abilitato
Se il cluster avanzato è abilitato, il comando gkectl update credentials
certificate-authorities rotate è sincrono. Il comando genera messaggi di stato nella workstation di amministrazione man mano che la rotazione della CA procede.
Una volta ruotata correttamente la CA, il comando si chiude e viene generato automaticamente un nuovo file kubeconfig. L'output comando fornisce il nome del nuovo file kubeconfig ed è simile al seguente:
Beginning CA rotation with generated CA ... Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has been updated.
Il nuovo kubeconfig si trova nella stessa directory del kubeconfig del cluster di amministrazione specificato nel comando. Il nome del nuovo kubeconfig
è USER_CLUSTER_NAME-kubeconfig.
Distribuire il nuovo file kubeconfig
Distribuisci il nuovo file kubeconfig a tutti coloro che utilizzano un file kubeconfig per interagire con il cluster.
Aggiornare i file di configurazione dell'autenticazione
Al termine della rotazione della CA, i file di configurazione dell'autenticazione devono essere aggiornati e ridistribuiti. Per ulteriori informazioni, vedi Gestire l'identità utente.
Rotazione dei certificati del piano di controllo
Senza rotazione, sia le CA del cluster utente sia i certificati del piano di controllo scadono cinque anni dopo la data di creazione del cluster. I certificati del piano di controllo del cluster utente vengono ruotati automaticamente entro dieci ore dall'upgrade di ogni cluster utente, ma le CA non vengono ruotate automaticamente. Ciò significa che, oltre agli upgrade regolari della versione, è necessario eseguire una rotazione della CA almeno una volta ogni cinque anni.
Per evitare che un cluster utente diventi non disponibile, i certificati del piano di controllo vengono ruotati entro dieci ore dall'upgrade di un cluster utente. In questo caso, viene visualizzato un messaggio nello stato di rotazione della CA del cluster utente.
Per visualizzare l'ultima versione a cui è stato eseguito l'upgrade di un cluster utente quando sono stati ruotati i certificati del piano di controllo:
gkectl update credentials certificate-authorities status \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Le informazioni vengono visualizzate alla fine del campo message entro dieci ore dall'upgrade. Ad esempio:
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
Risolvere i problemi relativi a una rotazione della CA
Il comando gkectl diagnose supporta il controllo dello stato previsto di una rotazione della CA completata rispetto a un cluster utente. Per istruzioni su come eseguire
gkectl diagnose su un cluster utente, vedi
Diagnosticare i problemi del cluster.
Se riscontri problemi con una rotazione della CA, contatta l'assistenza Google e fornisci l'output di gkectl diagnose.