Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Pour alterner les clés du compte de service dans Google Distributed Cloud, vous devez mettre à jour les identifiants de cluster existants à l'aide de la commande bmctl. Cette rotation des clés de compte de service peut faire partie de vos processus réguliers de mise à jour des identifiants, ou être effectuée en réponse à une exposition potentielle des clés. Lorsque vous mettez à jour les identifiants d'un cluster, les nouvelles informations sont transmises aux clusters d'administrateur ou hybrides, ou acheminées automatiquement vers les clusters d'utilisateur concernés gérés par un cluster d'administrateur.
Identifiants du cluster pouvant être mis à jour
Les clusters Google Distributed Cloud nécessitent plusieurs identifiants lors de leur création.
Vous définissez les identifiants dans la configuration du cluster lorsque vous créez un cluster d'administrateur, autonome ou hybride. Comme indiqué précédemment, les clusters d'utilisateur sont gérés par un cluster d'administrateur (ou un cluster hybride agissant en tant qu'administrateur) et réutilisent les mêmes identifiants que le cluster d'administrateur.
Vous pouvez mettre à jour les identifiants suivants et leurs secrets correspondants dans des clusters Google Distributed Cloud à l'aide de la commande bmctl :
Clé privée SSH : utilisée pour accéder au nœud.
Clé Artifact Registry (anthos-baremetal-gcr) : clé de compte de service utilisée pour s'authentifier auprès d'Artifact Registry pour l'extraction d'images.
Clé de compte de service de l'agent Connect (anthos-baremetal-connect) : clé de compte de service utilisée par les pods de l'agent Connect.
Clé de compte de service Connect Register (anthos-baremetal-register) : clé de compte de service utilisée pour s'authentifier auprès du Hub lors de l'enregistrement ou de l'annulation de l'enregistrement d'un cluster.
Clé de compte de service Cloud Operations (anthos-baremetal-cloud-ops) : clé de compte de service utilisée pour s'authentifier auprès des API Google Cloud Observability (journalisation et surveillance).
Mettre à jour les identifiants avec bmctl
Lorsque vous créez des clusters, Google Distributed Cloud crée des secrets Kubernetes en fonction de vos clés d'identification. Si vous générez de nouvelles clés, vous devez mettre à jour les secrets correspondants comme décrit dans les étapes suivantes. Si le nom ou le chemin d'accès à vos clés change, vous devez également mettre à jour le fichier de configuration du cluster correspondant.
Préparez les nouvelles valeurs des identifiants que vous souhaitez mettre à jour :
Générez une nouvelle clé privée SSH sur le poste de travail d'administrateur et assurez-vous que les machines du nœud de cluster disposent de la clé publique correspondante.
Mettez à jour la section des identifiants de votre fichier de configuration de cluster avec les chemins d'accès aux nouvelles clés.
Mettez à jour les secrets du cluster correspondants avec la commande bmctl update credentials, en ajoutant les options appropriées.
L'exemple suivant met à jour les identifiants pour une nouvelle clé privée SSH :
ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur ou autogéré.
CLUSTER_NAME : nom du cluster pour lequel vous mettez à jour la clé SSH.
SSH_KEY_PATH : chemin d'accès au fichier de clé SSH. Par défaut, bmctl vérifie les fichiers de clé SSH et de compte de service spécifiés dans le fichier de configuration du cluster. Si bmctl trouve un fichier de clé expirée, la commande échoue. Si le nouveau fichier de clé valide se trouve dans un emplacement différent de celui spécifié dans le fichier de configuration, incluez l'option --ignore-validation-errors pour éviter cet échec.
Pour obtenir la liste complète des options que vous pouvez utiliser avec la commande bmctl update
credentials, consultez la section Mettre à jour les identifiants dans la documentation de référence de la commande bmctl.
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,["To rotate the service account keys in Google Distributed Cloud, you update the\nexisting cluster credentials with the `bmctl` command. This service account key\nrotation might be as part of your regular processes to update credentials, or in\nresponse to a potential exposure of the keys. When you update cluster\ncredentials, the new information is passed to admin or hybrid clusters, or\nautomatically routed to affected user clusters managed by an admin cluster.\n\nCluster credentials that can be updated\n\nGoogle Distributed Cloud clusters require multiple credentials when they are created.\nYou set the credentials in the cluster config when you create an admin,\nstandalone, or hybrid cluster. User clusters, as noted previously, are managed\nby an admin cluster (or a hybrid cluster acting as admin), and will reuse the\nsame credentials from the admin cluster.\n\nFor more information about creating clusters and different cluster types,\nsee [Installation overview: choosing a deployment model](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/install-prep).\n\nYou can update the following credentials, and their corresponding secrets,\nin Google Distributed Cloud clusters with the `bmctl` command:\n\n- **SSH private key**: Used for node access.\n- **Artifact Registry key** (`anthos-baremetal-gcr`): Service account key used to authenticate with Artifact Registry for image pulling.\n- **Connect agent service account key** (`anthos-baremetal-connect`): Service account key used by Connect agent pods.\n- **Connect register service account key** (`anthos-baremetal-register`): Service account key used to authenticate with Hub when registering or unregistering a cluster.\n- **Cloud operations service account key** (`anthos-baremetal-cloud-ops`): Service account key to authenticate with Google Cloud Observability (logging \\& monitoring) APIs.\n\nUpdate credentials with `bmctl`\n\nWhen you create clusters, Google Distributed Cloud creates Kubernetes Secrets\nbased on your credential keys. If you generate new keys, you must update the\ncorresponding Secrets as described in the following steps. If the name or path\nto your keys change, you must also update the corresponding cluster\nconfiguration file.\n\n1. Prepare the new values for the credentials you want to update:\n\n - You can\n [generate new Google service account keys](/iam/docs/keys-create-delete#creating)\n through the Google Cloud CLI or through the Google Cloud console.\n\n - Generate new SSH private key on the admin workstation and make sure the\n cluster node machines have the corresponding public key.\n\n2. Update the credentials section of your cluster configuration file with paths\n to the new keys.\n\n3. Update the corresponding cluster Secrets with the `bmctl update credentials`\n command, adding the appropriate flags.\n\n The following example updates the credentials for a new SSH private key: \n\n bmctl update credentials --kubeconfig \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e \\\n --cluster \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --ssh-private-key-path \u003cvar translate=\"no\"\u003eSSH_KEY_PATH\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e: the path of the kubeconfig file\n of the admin or self-managing cluster.\n\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster that you're\n updating the SSH key for.\n\n - \u003cvar translate=\"no\"\u003eSSH_KEY_PATH\u003c/var\u003e: the path of the SSH key file. By\n default, `bmctl` checks the SSH and service account key files specified\n in the cluster configuration file. If `bmctl` finds an expired key file,\n the command fails. If you have the new valid key file in a different\n location than what's specified in the configuration file, include the\n `--ignore-validation-errors` flag to avoid this failure.\n\n For a complete list of the flags that you can use with the `bmctl update\n credentials` command, see [update\n credentials](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/bmctl#update_credentials) in the `bmctl`\n command reference."]]
