Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Google Distributed Cloud utilizza certificati e chiavi private per autenticare e criptare le connessioni tra i componenti di sistema nei cluster. L'autorità di certificazione (CA) del cluster gestisce questi certificati e queste chiavi. 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) per il cluster, la CA etcd e la CA front-proxy nello spazio dei nomi del cluster utente nel cluster di amministrazione.
I controller del cluster di amministrazione sostituiscono le autorità di certificato del cluster utente con quelle appena generate.
I controller del cluster amministrativo distribuiscono i nuovi certificati CA pubblici e le coppie di chiavi dei certificati principali 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 segreto per raccogliere le metriche etcd.
Per mantenere la comunicazione del cluster sicura, ruota la CA del cluster utente
periodicamente e ogni volta che si verifica una possibile violazione della sicurezza.
Prima di iniziare
Prima di ruotare l'autorità di certificazione del cluster, pianifica in base alle seguenti condizioni e agli impatti:
Assicurati che i cluster di amministrazione e utente siano alla versione 1.9.0 o successiva prima di iniziare la rotazione delle CA.
La rotazione delle CA è incrementale, il che consente ai componenti di sistema di comunicare durante la rotazione.
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.
Se il tuo cluster utente non dispone di un control plane ad alta disponibilità,
prendi in considerazione brevi periodi di inattività del control plane durante la rotazione della CA.
Le operazioni di gestione del cluster non sono consentite durante la rotazione della CA.
La durata della rotazione delle CA dipende dalle dimensioni del cluster. Ad esempio, la rotazione della CA può richiedere quasi due ore per un cluster con un piano di controllo e 50 nodi worker.
Limitazioni
La funzionalità di rotazione delle autorità di certificazione presenta le seguenti limitazioni:
La rotazione delle CA non aggiorna i certificati emessi manualmente da un amministratore, anche se sono firmati dall'autorità di certificazione del cluster. Aggiorna e ridistribuisci eventuali certificati emessi manualmente al termine della rotazione della CA del cluster utente.
Una volta avviata, la rotazione delle CA non può essere messa in pausa o annullata.
Avviare una rotazione dell'autorità di certificazione del cluster
Per impostazione predefinita, i certificati TLS hanno un periodo di scadenza di un anno.
Google Distributed Cloud rinnova questi certificati quando ruoti le autorità di certificazione. Google Distributed Cloud rinnova anche i certificati TLS durante gli upgrade dei cluster. Ti consigliamo di eseguire regolarmente l'upgrade dei cluster per mantenerli sicuri e supportati ed evitare che i certificati TLS scadano.
Utilizza il seguente comando per avviare la procedura di rotazione della CA:
CLUSTER_NAME: il nome del cluster per cui vuoi eseguire la rotazione delle CA.
KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione. Per i cluster autogestiti, questo file è il file kubeconfig del cluster.
Il comando bmctl esce dopo la rotazione della CA e la generazione di un nuovo file kubeconfig. Il percorso standard per il file kubeconfig è
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Risolvere i problemi relativi alla rotazione dell'autorità di certificazione 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:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-01 UTC."],[],[],null,["Google Distributed Cloud uses certificates and private keys to authenticate and encrypt\nconnections between system components in clusters. The cluster certificate\nauthority (CA) manages these certificates and keys. When you run the `bmctl\nupdate credentials certificate-authorities rotate` command,\nGoogle Distributed Cloud performs the following actions:\n\n- The command creates and uploads new cluster certificate authorities (CAs)\n for the cluster CA, the etcd CA, and the front-proxy CA to the user cluster\n namespace in the admin cluster.\n\n- The admin cluster controllers replace the user cluster certificate\n authorities with the newly generated ones.\n\n- The admin cluster controllers distribute the new public CA certificates and\n leaf certificate key pairs to user cluster system components.\n\n- The command also updates the `stackdriver-prometheus-etcd-scrape` Secret,\n which was created by Google Distributed Cloud during cluster creation.\n Prometheus requires this secret to collect etcd metrics.\n\nTo maintain secure cluster communication, rotate your user cluster CA\nperiodically and whenever there is a possible security breach.\n| **Important:** If your cluster certificates have expired, you must renew them manually to regain cluster operation. For more information and instructions, see [Renew expired cluster certificates manually](/kubernetes-engine/distributed-cloud/bare-metal/docs/troubleshooting/expired-certs).\n\nBefore you begin\n\nBefore you rotate your cluster's certificate authority, plan according to the\nfollowing conditions and impacts:\n\n- Ensure admin and user clusters are at version 1.9.0 or higher before\n starting the CA rotation.\n\n- CA rotation is incremental, allowing system components to communicate during\n the rotation.\n\n- A CA rotation restarts the API server, other control-plane processes, and\n each node in the cluster multiple times. Each stage of a CA rotation\n progresses similarly to a cluster upgrade. While the user cluster does\n remain operational during a CA rotation, you should expect that workloads\n will be restarted and rescheduled.\n\n- If your user cluster doesn't have a [high-availability control plane](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#controlplane-nodepoolspec-nodes),\n expect brief periods of control-plane downtime during CA rotation.\n\n- Cluster management operations aren't allowed during CA rotation.\n\n- CA rotation duration depends on the size of your cluster. For example, CA\n rotation may take close to two hours to complete for a cluster with one\n control plane and 50 worker nodes.\n\nLimitations\n\nThe certificate authority rotation capability has the\nfollowing limitations:\n\n- CA rotation doesn't update certificates issued manually by an administrator,\n even if the cluster CA signs the certificates. Update and redistribute any\n manually issued certificates after user cluster CA rotation is complete.\n\n- Once started, CA rotation can't be paused or rolled back.\n\nStart a cluster CA rotation\n\nBy default, TLS certificates have a 1-year expiration period.\nGoogle Distributed Cloud renews these certificates when you rotate certificate\nauthorities. Google Distributed Cloud also renews the TLS certificates during\ncluster upgrades. We recommend that you upgrade your clusters regularly to keep\nthem secure, supported, and to prevent TLS certificates from expiring.\n\nUse the following command to start the CA rotation process: \n\n bmctl update credentials certificate-authorities rotate --cluster \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster for which you want to rotate CAs.\n- \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e: the path to the admin cluster kubeconfig file. For self-managing clusters, this file is the cluster's kubeconfig file.\n\nThe `bmctl` command exits after the CA is rotated successfully and a new\nkubeconfig file is generated. The standard path for the kubeconfig file is\n`bmctl-workspace/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`-kubeconfig`.\n\nTroubleshoot a cluster CA rotation\n\nThe `bmctl update credentials` command displays the progress of the CA rotation.\nThe associated `update-credentials.log` file is saved to the following\ntimestamped directory: \n\n bmctl-workspace/\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e/log/update-credentials-\u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e"]]
