Rotazione delle autorità di certificazione del 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 ulteriori certificati foglia per i componenti del sistema. Il cluster di amministrazione gestisce la distribuzione dei certificati CA pubblici e delle coppie di chiavi dei certificati foglia ai componenti di sistema per stabilire la loro comunicazione sicura.

La funzionalità di rotazione CA del 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 principali del sistema per il cluster utente con CA appena generate e distribuisce i nuovi certificati CA pubblici e le coppie di chiavi dei certificati foglia ai componenti del sistema del cluster utente. La rotazione viene eseguita 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, nonché il 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 del proxy frontale protegge le comunicazioni 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 esterni al cluster. Sei tu a gestire questa CA e a generare 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, 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 del sistema.

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

  • Dopo una rotazione di un'autorità di certificazione, devi aggiornare il file kubeconfig del cluster utente e i file di configurazione dell'autenticazione. Questo perché il vecchio certificato del cluster è stato revocato e le credenziali nel file kubeconfig non funzionano più.

  • Una volta avviata la rotazione CA, non è possibile metterla in pausa o eseguirne il rollback.

  • Il completamento di una rotazione 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 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 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 restituisce CAVersion, che è un numero intero che il sistema incrementa automaticamente per differenziare le CA utilizzate prima e dopo una rotazione. Il comando segnala inoltre 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 ciascun componente del sistema.

    Se la rotazione CA è già stata completata, verrà 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, verrà 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 CA, devi ottenere un nuovo file kubeconfig del cluster utente dal cluster di amministrazione. perché la rotazione della CA revoca la CA su cui si basava 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

Al termine della 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 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 ciascun cluster utente, ma le CA non vengono ruotate automaticamente. Ciò significa che, oltre ai normali upgrade della versione, è necessario eseguire una rotazione 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 da un upgrade. Ad esempio:

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

Risoluzione dei problemi relativi alla rotazione di una CA

Il comando gkectl diagnose supporta il controllo dello stato previsto di una rotazione 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 riscontri problemi con una rotazione di CA, contatta l'Assistenza Google e fornisci l'output gkectl diagnose.