Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Wenn Sie die Dienstkontoschlüssel in Google Distributed Cloud rotieren möchten, aktualisieren Sie die vorhandenen Clusteranmeldedaten mit dem Befehl bmctl. Diese Dienstkontoschlüsselrotation kann Teil Ihrer regelmäßigen Prozesse zur Aktualisierung von Anmeldedaten oder als Reaktion auf eine potenzielle Offenlegung der Schlüssel erfolgen. Wenn Sie Clusteranmeldedaten aktualisieren, werden die neuen Informationen an Administrator- oder Hybridcluster übergeben oder automatisch an die betroffenen Nutzercluster weitergeleitet, die von einem Administratorcluster verwaltet werden.
Cluster-Anmeldedaten, die aktualisiert werden können.
Google Distributed Cloud-Cluster erfordern mehrere Anmeldedaten, wenn sie erstellt werden.
Sie legen die Anmeldedaten in der Clusterkonfiguration fest, wenn Sie einen Administrator-, eigenständigen oder hybriden Cluster erstellen. Nutzercluster wie zuvor beschrieben werden von einem Administratorcluster oder einem Hybridcluster verwaltet und verwenden dieselben Anmeldedaten vom Administrator-Cluster.
Sie können die folgenden Anmeldedaten und die zugehörigen Secrets in Google Distributed Cloud-Clustern mit dem Befehl bmctl aktualisieren:
Privater SSH-Schlüssel: Wird für den Knotenzugriff verwendet.
Container Registry-Schlüssel (anthos-baremetal-gcr): Dienstkontoschlüssel, der zum Authentifizieren bei Container Registry für das Abrufen von Images verwendet wird.
Connect-Agent-Dienstkontoschlüssel (anthos-baremetal-connect): Dienstkontoschlüssel, der von Connect-Agent-Pods verwendet wird.
Connect-Registry-Dienstkontoschlüssel (anthos-baremetal-register): Dienstkontoschlüssel, der zur Authentifizierung bei Hub bei der Registrierung oder Registrierung eines Clusters verwendet wird.
Cloud Operations-Dienstkontoschlüssel (anthos-baremetal-cloud-ops): Dienstkontoschlüssel zur Authentifizierung bei Google Cloud Observability-APIs (Logging und Monitoring).
Anmeldedaten mit bmctl aktualisieren
Wenn Sie Cluster erstellen, werden in Google Distributed Cloud Kubernetes-Secrets basierend auf Ihren Anmeldeschlüsseln erstellt. Wenn Sie neue Schlüssel generieren, müssen Sie die entsprechenden Secrets wie in den folgenden Schritten beschrieben aktualisieren. Wenn sich der Name oder Pfad zu Ihren Schlüsseln ändert, müssen Sie auch die entsprechende Clusterkonfigurationsdatei aktualisieren.
Bereiten Sie die neuen Werte für die Anmeldedaten vor, die Sie aktualisieren möchten:
Generieren Sie einen neuen privaten SSH-Schlüssel auf der Administrator-Workstation und achten Sie darauf, dass die Clusterknoten den entsprechenden öffentlichen Schlüssel haben.
Aktualisieren Sie den Abschnitt „Anmeldedaten“ Ihrer Clusterkonfigurationsdatei mit Pfaden zu den neuen Schlüsseln.
Aktualisieren Sie die entsprechenden Cluster-Secrets mit dem Befehl bmctl update credentials und fügen Sie die entsprechenden Flags hinzu.
Im folgenden Beispiel werden die Anmeldedaten für einen neuen privaten SSH-Schlüssel aktualisiert:
ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administrator- oder selbstverwalteten Clusters.
CLUSTER_NAME: der Name des Clusters, für den Sie den SSH-Schlüssel aktualisieren.
SSH_KEY_PATH: der Pfad zur SSH-Schlüsseldatei. Standardmäßig prüft bmctl die in der Clusterkonfigurationsdatei angegebenen SSH- und Dienstkontoschlüsseldateien. Wenn bmctl eine abgelaufene Schlüsseldatei findet, schlägt der Befehl fehl. Wenn sich die neue gültige Schlüsseldatei an einem anderen Speicherort als in der Konfigurationsdatei befindet, fügen Sie das Flag --ignore-validation-errors hinzu, um diesen Fehler zu vermeiden.
Eine vollständige Liste der Flags, die Sie mit dem Befehl bmctl update
credentials verwenden können, finden Sie in der Befehlsreferenz für bmctl unter update credentials (Anmeldedaten aktualisieren).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-04-22 (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."]]
