Ruota i certificati CA del cluster di amministrazione

Puoi ruotare i certificati dell'autorità di certificazione (CA) in un cluster di amministrazione Google Distributed Cloud per rinnovarli prima della scadenza. Questi certificati CA vengono creati con il cluster di amministrazione ed emettono i certificati utilizzati dai componenti di sistema di Kubernetes per autenticare la loro comunicazione. Esegui la rotazione con gkectl, quindi aggiorna i file kubeconfig, che vengono invalidati dalla rotazione. Questo documento si applica solo ai cluster di amministrazione. Per i cluster utente, consulta Rotazione dei certificati CA del cluster utente.

Informazioni sui certificati CA del cluster di amministrazione

Il sistema Kubernetes utilizza tre certificati CA in un cluster di amministrazione:

  • Il certificato CA etcd protegge la comunicazione dal server API Kubernetes alle repliche etcd e anche la comunicazione tra le repliche etcd. Questo certificato è autofirmato.

  • Il certificato CA del cluster protegge la comunicazione tra il server API Kubernetes e tutti i client API Kubernetes interni, ad esempio kubelet, il gestore dei controller e lo scheduler. Questo certificato è autofirmato.

  • Il certificato CA del proxy front-end protegge la comunicazione con le API aggregate. Questo certificato è autofirmato.

Puoi utilizzare gkectl per attivare una rotazione dei certificati. Durante una rotazione, gkectl sostituisce i certificati CA del sistema principale per il cluster di amministrazione con certificati appena generati. Quindi distribuisce i nuovi certificati CA, i certificati foglia e le chiavi private ai componenti di sistema del cluster di amministrazione. 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 workload e i nodi vengono riavviati durante la rotazione.

Senza rotazione, i certificati CA e i certificati del control plane scadono dopo un periodo di tempo dalla data di creazione del cluster.

Il periodo di scadenza dipende dal tipo di cluster e dalla versione di creazione:

  • Cluster avanzati:
    • Scadenza di 10 anni
  • Cluster non avanzati:
    • Creato prima della versione 1.5: scadenza di 10 anni
    • Creati tra le versioni 1.5 e 1.16: scadenza di 5 anni
    • Creato dopo la versione 1.16: scadenza di 30 anni

I certificati del control plane vengono ruotati automaticamente durante un upgrade del cluster, ma le CA non vengono ruotate automaticamente. Ciò significa che, oltre ai normali upgrade di versione, è necessario eseguire una rotazione della CA prima della data di scadenza della CA.

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 ai certificati etcd, del cluster e del proxy front-end menzionati 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.

  • La rotazione dei certificati CA riavvia più volte il server API Kubernetes, altri processi del control plane e ogni nodo nel cluster di amministrazione. Ogni fase di una rotazione procede in modo simile a un upgrade del cluster. Sebbene il cluster di amministrazione e i cluster utente gestiti dal cluster di amministrazione rimangano operativi durante una rotazione dei certificati, tieni presente che i workload nel cluster di amministrazione verranno riavviati e ripianificati. Dovresti anche aspettarti brevi periodi di inattività per il control plane del cluster di amministrazione e il control plane del cluster utente.

  • Devi aggiornare il file kubeconfig del cluster di amministrazione durante una rotazione dei certificati e di nuovo al termine della rotazione. Questo perché il certificato del cluster precedente viene revocato e le credenziali nel file kubeconfig non funzioneranno più.

  • Una volta avviata, la rotazione dei certificati CA non può essere annullata.

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

  • Se viene interrotto, il processo di rotazione dei certificati può essere ripreso eseguendo nuovamente lo stesso comando. Tuttavia, devi assicurarti che venga eseguito un solo comando di rotazione alla volta.

Avvia la rotazione

Per avviare la rotazione dei certificati, esegui questo comando:

gkectl update credentials certificate-authorities rotate \
    --admin-cluster \
    --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Sostituisci quanto segue:

  • ADMIN_CLUSTER_CONFIG: il percorso del file di configurazione del cluster di amministrazione

  • 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

Il comando gkectl update credentials certificate-authorities rotate avvia ed esegue la prima metà della rotazione. Il comando viene quindi messo in pausa per consentirti di eseguire il comando successivo per aggiornare il file kubeconfig.

Aggiorna il file kubeconfig

Quando il comando gkectl update credentials certificate-authorities rotate viene messo in pausa, aggiorna il file kubeconfig per il cluster di amministrazione. In questo modo, nel file kubeconfig vengono inseriti un nuovo certificato client e un nuovo certificato CA. Il vecchio certificato client viene rimosso dal file kubeconfig, mentre il vecchio certificato CA rimane nel file kubeconfig.

gkectl update credentials certificate-authorities update-kubeconfig \
  --admin-cluster \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Continua la rotazione

Esegui questo comando per eseguire la seconda metà della procedura. Il comando non procede finché gkectl non verifica che il file kubeconfig aggiornato si trovi nella directory corrente.

gkectl update credentials certificate-authorities rotate \
  --admin-cluster \
  --complete \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Al termine della rotazione, viene segnalata la versione attuale della CA.

Aggiorna di nuovo il file kubeconfig

Al termine della seconda metà della rotazione, aggiorna nuovamente il file kubeconfig. In questo modo, il vecchio certificato CA viene rimosso dal file kubeconfig.

gkectl update credentials certificate-authorities update-kubeconfig \
  --admin-cluster \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_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. Il file kubeconfig specificato nel comando viene sostituito con uno nuovo. L'output comando è simile al seguente:

Beginning CA rotation with generated CA
...
Successfully rotated CA for admin cluster. The kubeconfig file
"/home/ubuntu/kubeconfig" has been updated.
Done rotating certificate-authorities

Distribuisci il nuovo file kubeconfig

Distribuisci il nuovo file kubeconfig del cluster di amministrazione a tutti gli utenti del cluster.