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 set di autorità di certificazione (CA) per ogni cluster utente e utilizza i certificati CA per emettere ulteriori certificati foglia per i componenti di sistema. Il cluster di amministrazione gestisce la distribuzione delle coppie di chiavi del certificato CA pubblico e del certificato foglia ai componenti di sistema per stabilire la comunicazione sicura.
La funzionalità di rotazione della CA del cluster utente consente di attivare una 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 leaf ai componenti di sistema del cluster utente. La rotazione avviene in modo incrementale, in modo che i componenti del sistema possano continuare a comunicare durante la rotazione. Tieni presente, tuttavia, che i carichi di lavoro e i nodi vengono riavviati durante la rotazione.
Per ogni cluster utente, il cluster di amministrazione gestisce tre CA di sistema:
- 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.
- L'autorità di certificazione 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 per i client
al di fuori del cluster. Gestisci questa CA e genera manualmente il certificato SNI. Né questa CA né il certificato SNI sono interessati dalla funzionalità di rotazione della CA del cluster di utenti.
Limitazioni
Tieni presente la seguente limitazione relativa ai cluster avanzati:
- Versione 1.31: la rotazione delle CA non è supportata sui cluster avanzati.
- Versione 1.32 e successive: la rotazione della CA è supportata nei cluster avanzati, ma esistono alcune piccole differenze indicate, ove applicabile, in questo documento.
La rotazione dei certificati CA è limitata alle CA etcd, cluster e front-proxy 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.
La rotazione della CA riavvia più volte il server API, altri processi del control plane e ogni nodo del cluster. Ogni fase di una rotazione della CA procede in modo simile a un upgrade del cluster. Anche se il cluster utente rimane operativo durante la rotazione dell'autorità di certificazione, devi prevedere che i carichi di lavoro vengano riavviati e riprogrammati. Dovresti anche aspettarti brevi periodi di inattività del control plane se il tuo cluster utente non ha un control plane ad alta disponibilità.
Dopo una rotazione della CA, devi aggiornare i file di configurazione di autenticazione e kubeconfig del cluster utente. Questo perché il vecchio certificato del cluster è revocato e le credenziali nel file kubeconfig non funzionano più.
Una volta avviata, la rotazione della CA non può essere sospesa o annullata.
Il completamento di una rotazione dell'autorità di certificazione potrebbe richiedere molto tempo, a seconda delle dimensioni del cluster utente.
Esegui 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 attivato:
Non abilitato
Se il cluster avanzato non è abilitato sul cluster, il comando è asincrono
e avvia la rotazione della CA, quindi esce. Non è necessario monitorare l'output del comando per l'intera durata della rotazione della CA. Puoi invece 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 restituisce CAVersion, un numero intero che
il sistema incrementa automaticamente per distinguere le CA utilizzate prima e
dopo una rotazione. Il comando restituisce anche uno stato (True o False)
che indica se la rotazione della CA è completata e un messaggio che descrive
quale CAVersion è attualmente in uso da ciascun componente del sistema.
Se la rotazione della CA è già stata completata, viene visualizzato un messaggio simile a questo:
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 a questo:
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.
Aggiorna 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 dell'autorità di certificazione revoca l'autorità di certificazione su cui si basava il vecchio file kubeconfig.
Recupera 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 restituisce
messaggi di stato alla workstation di amministrazione man mano che la rotazione della CA procede.
Una volta eseguito correttamente il rollover della CA, il comando viene chiuso e viene generato automaticamente un nuovo file kubeconfig. L'output del 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
che hai 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 lo utilizzano per interagire con il cluster.
Aggiorna 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 control plane
Senza rotazione, sia le CA dei cluster utente sia i certificati del control plane scadono cinque anni dopo la data di creazione del cluster. I certificati del control plane del cluster utente vengono ruotati automaticamente entro dieci ore da ogni upgrade del cluster utente, ma le CA non vengono ruotate automaticamente. Ciò significa che la rotazione della CA deve essere eseguita almeno una volta ogni cinque anni, oltre agli aggiornamenti regolari delle versioni.
Per evitare che un cluster utente diventi non disponibile, i certificati del control plane vengono ruotati entro dieci ore dall'upgrade del cluster utente. Quando ciò accade, viene visualizzato un messaggio nello stato di rotazione della CA del cluster di utenti.
Per visualizzare l'ultima versione a cui è stato eseguito l'upgrade di un cluster utente quando sono stati ruotati i certificati del control plane:
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.
Risoluzione dei problemi relativi a una rotazione delle CA
Il comando gkectl diagnose supporta il controllo dello stato previsto di una rotazione dell'autorità di certificazione completata rispetto a un cluster utente. Per istruzioni su come eseguire
gkectl diagnose su un cluster utente, vedi
Diagnostica dei problemi relativi ai cluster.
Se riscontri problemi con la rotazione di un'autorità di certificazione, contatta l'assistenza Google e
fornisci l'output di gkectl diagnose.