Rotazione delle autorità di certificazione dei cluster utente

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 aggiuntivi per i componenti di sistema. Il cluster di amministrazione gestisce la distribuzione dei certificati CA pubblici e delle coppie di chiavi dei certificati principali ai componenti di sistema per stabilire la loro comunicazione sicura.

La funzionalità di rotazione dell'autorità di certificazione dei cluster utente consente di attivare una rotazione dei certificati di sistema di base in un cluster utente. Durante una rotazione, il cluster di amministrazione sostituisce le CA di sistema di base per il cluster di utenti con CA appena generate e distribuisce i nuovi certificati CA pubblici e le coppie di chiavi dei certificati principali ai componenti di sistema del cluster di utenti. 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.
  • Il certificato CA del proxy anteriore protegge la comunicazione con le API aggregate. Questa CA è autofirmata.

Inoltre, potresti 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 fornire l'API Kubernetes ai client al di fuori del 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 di utenti.

Limitazioni

  • 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 sono firmati dalle CA di sistema.

  • Una rotazione della CA riavvia il server API, altri processi del piano di controllo e ogni nodo del cluster più volte. Ogni fase di una rotazione della CA procede in modo simile a un upgrade del cluster. Sebbene il cluster utente rimanga operativo durante la rotazione dell'autorità di certificazione, è normale che i carichi di lavoro vengano riavviati e riprogrammati. Dovresti anche aspettarti brevi periodi di interruzione del servizio del piano di controllo se il tuo cluster di utenti non dispone di un piano di controllo ad alta disponibilità.

  • Devi aggiornare il file kubeconfig del cluster utente e i file di configurazione dell'autenticazione dopo una rotazione della CA. Questo accade perché il vecchio certificato del cluster è stato revocato e le credenziali nel file kubeconfig non funzionano più.

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

  • La rotazione dell'autorità di certificazione 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_CONFIGE: il percorso del file di configurazione del cluster utente

    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione

    Se la rotazione della CA si avvia 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

  2. Visualizza lo stato della rotazione:

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

    Il comando precedente riporta CAVersion, che è un numero intero incrementato automaticamente dal sistema per distinguere le CA utilizzate prima e dopo una rotazione. Il comando riporta 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 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 delle 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

Al termine della rotazione della CA, devi recuperare un nuovo file kubeconfig del cluster utente dal cluster di amministrazione. Questo accade perché la rotazione dell'autorità di certificazione revoca l'autorità di certificazione 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

Distribuisci il nuovo file kubeconfig a tutti gli utenti che utilizzano un file kubeconfig 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, consulta Gestire l'identità utente.

Rotazione dei certificati del piano di controllo

Senza la rotazione, sia le CA dei cluster utente sia i certificati del piano di controllo 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 deve essere eseguita una rotazione delle CA almeno una volta ogni cinque anni, oltre agli aggiornamenti regolari delle versioni.

Per evitare che un cluster utente non sia più disponibile, i certificati del piano di controllo vengono ruotati entro dieci ore dall'upgrade del cluster utente. In questo caso, 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 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 da un upgrade. Ad esempio:

Last Leaf Certificates Rotation Version: 1.16.0-gke.0.

Risolvere i problemi relativi alla 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 di utenti. Per istruzioni su come eseguire gkectl diagnose su un cluster di utenti, consulta Diagnostica dei problemi relativi ai cluster. Se riscontri problemi con la rotazione delle CA, contatta l'Assistenza Google e fornisci l'output gkectl diagnose.