Google Distributed Cloud ti consente di ruotare le autorità di certificazione (CA) dei cluster utente per aggiornare i certificati e le chiavi private che autenticano e criptano la comunicazione di sistema. La rotazione periodica della CA del cluster utente e dopo qualsiasi potenziale incidente di sicurezza ti aiuta a mantenere la sicurezza del cluster. La rotazione automatica della CA richiede certificati attivi e validi.
Se i certificati del cluster sono scaduti, devi invece rinnovarli manualmente per ripristinare le operazioni del cluster.
Come funziona la rotazione delle CA
Quando esegui il comando bmctl update credentials certificate-authorities rotate, Google Distributed Cloud esegue le seguenti azioni:
Il comando crea e carica nuove autorità di certificazione (CA) del cluster per la CA del cluster, la CA etcd e la CA del proxy front-end nello spazio dei nomi del cluster utente nel cluster di amministrazione.
I controller del cluster di amministrazione sostituiscono le autorità di certificazione del cluster utente con quelle appena generate.
I controller del cluster di amministrazione distribuiscono i nuovi certificati CA pubblici e le coppie di chiavi dei certificati foglia ai componenti di sistema del cluster utente.
Il comando aggiorna anche il secret
stackdriver-prometheus-etcd-scrape, creato da Google Distributed Cloud durante la creazione del cluster. Prometheus richiede questo secret per raccogliere le metriche etcd.
Prima di iniziare
Prima di ruotare l'autorità di certificazione del cluster, pianifica in base alle seguenti condizioni e impatti:
Assicurati che i cluster di amministrazione e utente siano alla versione 1.9.0 o successive prima di avviare la rotazione delle CA.
La rotazione della CA è incrementale, consentendo ai componenti di sistema di comunicare durante la rotazione.
Una rotazione della 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. Sebbene il cluster utente rimanga operativo durante una rotazione delle CA, tieni presente che i workload verranno riavviati e ripianificati.
Se il tuo cluster utente non dispone di un control plane ad alta affidabilità, prevedi brevi periodi di inattività del control plane durante la rotazione della CA.
Le operazioni di gestione dei cluster non sono consentite durante la rotazione delle CA.
La durata della rotazione della CA dipende dalle dimensioni del cluster. Ad esempio, la rotazione delle CA potrebbe richiedere quasi due ore per un cluster con un control plane e 50 nodi worker.
Limitazioni
La funzionalità di rotazione delle autorità di certificazione presenta le seguenti limitazioni:
La rotazione della CA non aggiorna i certificati emessi manualmente da un amministratore, anche se la CA del cluster firma i certificati. Aggiorna e ridistribuisci tutti i certificati emessi manualmente dopo il completamento della rotazione della CA del cluster utente.
Una volta avviata, la rotazione delle CA non può essere messa in pausa o annullata.
Avvia una rotazione della CA del cluster
Per impostazione predefinita, i certificati TLS hanno un periodo di scadenza di un anno, mentre il certificato clientconfig-operator ha un periodo di scadenza di 10 anni (per le versioni precedenti alla 1.36.100, il certificato clientconfig-operator scade dopo cinque anni).
Google Distributed Cloud rinnova questi certificati quando esegui la rotazione delle autorità di certificazione. Google Distributed Cloud rinnova anche i certificati TLS di un anno durante gli upgrade dei cluster. Per le versioni precedenti alla 1.36.100, ti consigliamo di eseguire regolarmente l'upgrade dei cluster per mantenerli sicuri e supportati, per evitare la scadenza dei certificati TLS ed eseguire una rotazione della CA almeno una volta ogni cinque anni.
Utilizza il seguente comando per avviare il processo di rotazione delle CA:
bmctl update credentials certificate-authorities rotate --cluster CLUSTER_NAME \
--kubeconfig KUBECONFIG
Sostituisci quanto segue:
CLUSTER_NAME: il nome del cluster per cui vuoi ruotare le CA.KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster con gestione autonoma, questo file è il file kubeconfig del cluster.
Il comando bmctl viene chiuso dopo che la CA è stata ruotata correttamente e viene generato un nuovo file kubeconfig. Il percorso standard per il file kubeconfig è bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Risolvi i problemi relativi alla rotazione delle CA del cluster
Il comando bmctl update credentials mostra l'avanzamento della rotazione della CA.
Il file update-credentials.log associato viene salvato nella seguente directory con timestamp:
bmctl-workspace/CLUSTER_NAME/log/update-credentials-TIMESTAMP