Autorità di certificazione del cluster utente in rotazione

GKE su VMware 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 del sistema. Il cluster di amministrazione gestisce la distribuzione dei certificati CA pubblici e delle coppie di chiavi del certificato foglia ai componenti di sistema per stabilirne la comunicazione sicura.

La funzionalità di rotazione CA del cluster utente consente di attivare una rotazione dei certificati di sistema principale in un cluster utente. Durante una rotazione, il cluster di amministrazione sostituisce le CA del sistema principali per il cluster utente con CA appena generate e distribuisce i nuovi certificati CA pubblici e le coppie di chiavi del certificato foglia 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. Tuttavia, tieni presente 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, oltre che al traffico tra le repliche etcd. Questa CA è autofirmata.
  • La CA del cluster protegge le comunicazioni tra il server API e tutti i client API Kubernetes interni (kubelet, controller, scheduler). Questa CA è autofirmata.
  • La CA front-proxy protegge la comunicazione con le API aggregate. Questa CA è autofirmata.

Inoltre, è possibile che tu stia utilizzando una CA 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 all'esterno del cluster. Gestisci questa CA e genera manualmente il certificato SNI. Né questa CA né il certificato SNI sono interessati dalla funzionalità di rotazione delle CA del cluster utente.

Limitazioni

  • La rotazione del certificato CA è limitata alle CA etcd, del cluster e del front-proxy menzionate in precedenza.

  • La rotazione dei certificati CA è limitata ai certificati emessi automaticamente da GKE su VMware. Non aggiorna i certificati emessi manualmente da un amministratore, anche se sono firmati dalle CA del sistema.

  • Una rotazione della CA riavvia più volte il server API, altri processi del piano di controllo e ogni nodo nel cluster. Ogni fase di una rotazione di CA avanza in modo simile all'upgrade di un cluster. Anche se il cluster utente rimane operativo durante una rotazione della CA, è normale che i carichi di lavoro vengano riavviati e ripianificati. Dovresti inoltre aspettarti brevi periodi di inattività del piano di controllo se il tuo cluster utente non ha un piano di controllo ad alta disponibilità.

  • Devi aggiornare il file kubeconfig e i file di configurazione dell'autenticazione del cluster utente dopo una rotazione della CA. Questo perché il vecchio certificato di 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 rollback.

  • Il completamento di una rotazione della CA potrebbe richiedere molto tempo, a seconda delle dimensioni del cluster utente.

Esegui una rotazione 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 a questo:

    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, 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

  2. Visualizza 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, vedrai 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 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 ottenere un nuovo file kubeconfig del cluster utente dal cluster di amministrazione. Questo perché la rotazione della CA revoca la CA su cui era basato il file kubeconfig precedente.

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 coloro che utilizzano un file kubeconfig per interagire con il cluster.

Aggiorna i file di configurazione dell'autenticazione

Una volta completata la rotazione della 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:

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 dalla data di creazione del cluster. I certificati del piano di controllo 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 una rotazione della CA deve essere eseguita almeno una volta ogni cinque anni oltre agli upgrade della versione normale.

Per evitare che un cluster utente diventi non disponibile, i certificati del piano di controllo vengono ruotati entro dieci ore dopo l'upgrade del cluster utente. Quando ciò accade, 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 da un upgrade. Ad esempio:

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

Risoluzione dei problemi relativi alla rotazione di 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, consulta Diagnostica dei problemi del cluster. Se si verificano problemi con una rotazione CA, contatta l'Assistenza Google e fornisci l'output gkectl diagnose.