Ruota le autorità di certificazione del cluster utente

Puoi ruotare le autorità di certificazione (CA) del sistema principale in un cluster utente Google Distributed Cloud per rinnovarle prima della scadenza. Durante una rotazione, il cluster di amministrazione sostituisce le CA del cluster utente con CA appena generate, quindi distribuisce ai componenti di sistema i certificati e le coppie di chiavi emessi dalle nuove CA. La rotazione è incrementale, quindi i componenti del sistema possono continuare a comunicare, ma i workload e i nodi vengono riavviati. Per ruotare le CA in un cluster di amministrazione, consulta Rotazione dei certificati CA del cluster di amministrazione.

Informazioni sulle CA dei cluster utente

Il cluster di amministrazione gestisce tre CA di sistema autofirmate per ogni cluster utente. Ogni CA emette certificati, chiamati certificati foglia, per i singoli componenti del sistema, che li utilizzano per autenticare e criptare le proprie connessioni:

  • La CA etcd protegge la comunicazione dal server API alle repliche etcd e il traffico tra le repliche etcd.
  • La CA del cluster protegge la comunicazione tra il server API e tutti i client API Kubernetes interni (kubelet, controller, scheduler).
  • La CA front-proxy protegge la comunicazione con le API aggregate.

Puoi anche utilizzare una CA dell'organizzazione per firmare il certificato configurato dall'opzione authentication.sni, che fornisce l'API Kubernetes ai client esterni al cluster. Sei tu a gestire questa CA e a generare manualmente il certificato SNI. La rotazione della CA del cluster utente non influisce sulla CA dell'organizzazione o sul certificato SNI.

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 delle 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, del cluster e del 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 delle CA riavvia più volte il server API, altri processi del control plane e ogni nodo del cluster. Ogni fase di una rotazione delle CA procede in modo simile a un upgrade del cluster. Anche se il cluster utente rimane operativo durante una rotazione della CA, tieni presente che i workload verranno riavviati e ripianificati. Dovresti anche aspettarti brevi periodi di inattività del control plane se il tuo cluster utente non dispone di un control plane ad alta affidabilità.

  • Dopo una rotazione delle CA, devi aggiornare il file kubeconfig del cluster utente e i file di configurazione dell'autenticazione. Questo perché il certificato del cluster precedente viene revocato e le credenziali nel file kubeconfig non funzionano più.

  • Una volta avviata, la rotazione della CA non può essere messa in pausa o sottoposta a rollback.

  • La rotazione delle CA potrebbe richiedere molto tempo, a seconda delle dimensioni del cluster utente.

Esegui una rotazione della CA

  1. Avvia la rotazione:

    gkectl update credentials certificate-authorities rotate \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Sostituisci 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:

Non abilitato

Se il cluster avanzato non è abilitato sul cluster, il comando è asincrono, avvia la rotazione della CA e poi esce. Non è necessario osservare 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 delle 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 segnala anche uno stato (True o False) che indica se la rotazione della CA è stata completata e un messaggio che descrive quale CAVersion è attualmente in uso da parte di 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.

Aggiorna le credenziali del cluster utente

Sui cluster che non hanno il cluster avanzato abilitato, 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 restituisce messaggi di stato alla workstation di amministrazione man mano che la rotazione delle CA procede.

Dopo che la rotazione della CA è stata completata, il comando viene chiuso 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.

Distribuisci il nuovo file kubeconfig

Distribuisci il nuovo file kubeconfig a tutti coloro che utilizzano un file kubeconfig per interagire con il cluster.

Aggiorna i file di configurazione dell'autenticazione

Al termine della rotazione delle CA, i file di configurazione dell'autenticazione devono essere aggiornati e ridistribuiti. Per saperne di più, consulta Gestisci l'identità utente.

Rotazione dei certificati del control plane

Senza rotazione, sia le CA dei cluster utente sia i certificati del control plane scadono dieci anni dopo la data di creazione del cluster (per le versioni precedenti alla 1.36.100, questi certificati scadono dopo cinque anni). 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 è necessario eseguire una rotazione della CA almeno una volta ogni dieci anni (cinque anni per le versioni precedenti alla 1.36.100), oltre ai normali upgrade di versione.

Per evitare che un cluster utente non sia disponibile, i certificati del control plane vengono ruotati entro dieci ore dall'upgrade di un cluster utente. In questo caso, viene visualizzato un messaggio nello stato di rotazione delle CA del cluster utente.

Per visualizzare l'ultima versione a cui è stato eseguito l'upgrade di un cluster utente quando i certificati del control plane sono stati ruotati:

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 alla rotazione delle CA

Il comando gkectl diagnose supporta il controllo dello stato previsto di una rotazione delle CA completata rispetto a un cluster utente. Per istruzioni su come eseguire gkectl diagnose su un cluster utente, consulta Diagnosi dei problemi del cluster. Se riscontri problemi con una rotazione della CA, contatta l'Assistenza Google e fornisci l'output di gkectl diagnose.