Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Para rotar las claves de cuenta de servicio en Google Distributed Cloud, debes actualizar las credenciales del clúster existentes con el comando bmctl. Esta rotación de claves de cuenta de servicio puede ser parte de tus procesos habituales para actualizar las credenciales o en respuesta a una posible exposición de las claves. Cuando actualizas las credenciales del clúster, la información nueva se pasa a los clústeres de administrador o híbridos, o se enruta automáticamente a los clústeres de usuario afectados administrados por un clúster de administración.
Credenciales de clúster que se pueden actualizar
Los clústeres de Google Distributed Cloud requieren varias credenciales cuando se crean.
Debes establecer las credenciales en la configuración del clúster cuando creas un clúster administrativo, independiente o híbrido. Un clúster de administrador (o un clúster híbrido que actúa como administrador) administra los clústeres de usuario (como ya se mencionó), y volverá a usar las mismas credenciales del clúster de administrador.
Puedes actualizar las siguientes credenciales y sus secretos correspondientes en clústeres de Google Distributed Cloud con el comando bmctl:
Clave privada SSH: Se usa para el acceso a los nodos.
Clave de Artifact Registry (anthos-baremetal-gcr): Es la clave de cuenta de servicio que se usa para autenticarse con Artifact Registry y extraer imágenes.
Clave de la cuenta de servicio del agente de Connect (anthos-baremetal-connect): Es la clave de la cuenta de servicio que usan los pods del agente de Connect.
Clave de cuenta de servicio de registro de Connect (anthos-baremetal-register): Es la clave de cuenta de servicio que se usa para autenticarse con Hub cuando se registra o anula el registro de un clúster.
Clave de la cuenta de servicio de operaciones en la nube (anthos-baremetal-cloud-ops): Es la clave de la cuenta de servicio para autenticarse con las APIs de Google Cloud Observability (registro y supervisión).
Actualiza las credenciales con bmctl
Cuando creas clústeres, Google Distributed Cloud crea secretos de Kubernetes
basados en tus claves de credenciales. Si generas claves nuevas, debes actualizar los secretos correspondientes como se describe en los siguientes pasos. Si cambia el nombre o la ruta de acceso a tus claves, también debes actualizar el archivo de configuración del clúster correspondiente.
Prepara los valores nuevos de las credenciales que deseas actualizar:
Genera una nueva clave privada de SSH en la estación de trabajo de administrador y asegúrate de que las máquinas de nodo del clúster tengan la clave pública correspondiente.
Actualiza la sección de credenciales del archivo de configuración del clúster con las rutas de acceso a las claves nuevas.
Actualiza los secretos del clúster correspondientes con el comando bmctl update credentials y agrega las marcas adecuadas.
En el siguiente ejemplo, se actualizan las credenciales de una nueva clave privada SSH:
ADMIN_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador o autoadministrado.
CLUSTER_NAME: Es el nombre del clúster para el que actualizas la clave SSH.
SSH_KEY_PATH: Es la ruta de acceso al archivo de clave SSH. De forma predeterminada, bmctl verifica los archivos de claves de SSH y de la cuenta de servicio especificados en el archivo de configuración del clúster. Si bmctl encuentra un archivo de clave vencido, el comando falla. Si tienes el nuevo archivo de claves válido en una ubicación diferente a la que se especifica en el archivo de configuración, incluye la marca --ignore-validation-errors para evitar este error.
Para obtener una lista completa de las marcas que puedes usar con el comando bmctl update
credentials, consulta Cómo actualizar credenciales en la referencia del comando bmctl.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]