Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Google Distributed Cloud utilise des certificats et des clés privées pour authentifier et chiffrer les connexions entre les composants système des clusters. L'autorité de certification du cluster gère ces certificats et clés. Lorsque vous exécutez la commande bmctl
update credentials certificate-authorities rotate, Google Distributed Cloud effectue les actions suivantes:
La commande crée et importe de nouvelles autorités de certification de cluster pour l'autorité de certification de cluster, l'autorité de certification d'etcd et l'autorité de certification de proxy frontal dans l'espace de noms du cluster d'utilisateur au sein du cluster d'administrateur.
Les contrôleurs de cluster d'administrateur remplacent les autorités de certification du cluster d'utilisateur par celles nouvellement générées.
Les contrôleurs de cluster d'administrateur distribuent les nouveaux certificats d'autorité de certification publique et les paires de clés de certificat du serveur aux composants du système de cluster d'utilisateur.
La commande met également à jour le secret stackdriver-prometheus-etcd-scrape, créé par Google Distributed Cloud lors de la création du cluster.
Prometheus a besoin de ce secret pour collecter les métriques etcd.
Pour maintenir une communication sécurisée entre les clusters, faites tourner régulièrement l'autorité de certification de votre cluster d'utilisateur chaque fois qu'il existe une brèche de sécurité possible.
Avant de commencer
Avant d'effectuer la rotation de votre autorité de certification de votre cluster, planifiez en fonction des conditions et des impacts suivants :
Assurez-vous que les clusters d'administrateur et d'utilisateur sont à la version 1.9.0 ou ultérieure avant de démarrer la rotation de l'autorité de certification.
La rotation des autorités de certification est incrémentielle, ce qui permet aux composants système de communiquer pendant la rotation.
Une rotation des autorités de certification doit redémarrer le serveur d'API, d'autres processus du plan de contrôle, ainsi que chaque nœud du cluster plusieurs fois. Chaque étape d'une rotation des autorités de certification se déroule de la même manière qu'une mise à niveau de cluster. Bien que le cluster d'utilisateur reste opérationnel pendant la rotation des autorités de certification, attendez-vous à ce que les charges de travail soient redémarrées et replanifiées.
Si votre cluster d'utilisateur ne dispose pas d'un plan de contrôle à haute disponibilité, attendez-vous à de courtes périodes d'interruption du plan de contrôle lors de la rotation de l'autorité de certification.
Les opérations de gestion des clusters ne sont pas autorisées lors de la rotation de l'autorité de certification.
La durée de la rotation des autorités de certification dépend de la taille de votre cluster. Par exemple, la rotation des autorités de certification peut prendre près de deux heures pour un cluster comportant un plan de contrôle et 50 nœuds de calcul.
Limites
La fonctionnalité de rotation des autorités de certification présente les limitations suivantes :
La rotation des autorités de certification ne met pas à jour les certificats émis manuellement par un administrateur, même si l'autorité de certification du cluster signe les certificats. Mettez à jour et redistribuez les certificats émis manuellement une fois la rotation de l'autorité de certification du cluster d'utilisateur terminée.
Une fois démarrée, la rotation de l'autorité de certification ne peut pas être suspendue ou annulée.
Démarrer une rotation des autorités de certification de cluster
Par défaut, les certificats TLS ont une période d'expiration d'un an.
Google Distributed Cloud renouvelle ces certificats lorsque vous faites tourner les autorités de certification. Google Distributed Cloud renouvelle également les certificats TLS lors des mises à niveau de cluster. Nous vous recommandons de mettre à niveau vos clusters régulièrement pour les sécuriser, les prendre en charge et éviter que les certificats TLS n'expirent.
Utilisez la commande suivante pour démarrer le processus de rotation de l'autorité de certification :
CLUSTER_NAME : nom du cluster pour lequel vous souhaitez alterner les autorités de certification.
KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur. Pour les clusters autogérés, ce fichier est le fichier kubeconfig du cluster.
La commande bmctl se ferme après la rotation de l'autorité de certification et la génération d'un nouveau fichier kubeconfig. Le chemin d'accès standard pour le fichier kubeconfig est bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Résoudre les problèmes liés à la rotation des autorités de certification de cluster
La commande bmctl update credentials affiche la progression de la rotation de l'autorité de certification.
Le fichier update-credentials.log associé est enregistré dans le répertoire horodaté suivant :
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/01 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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"]]
