Vorbereitete Anmeldedaten für Nutzercluster konfigurieren

In diesem Dokument wird gezeigt, wie vorbereitete Anmeldedaten für Nutzercluster in Google Distributed Cloud konfiguriert werden.

Mit vorbereiteten Anmeldedaten können Sie Anmeldedaten für Ihre Nutzercluster in Secrets in Ihrem Administratorcluster speichern. Dies erhöht die Sicherheit, da Sie beim Erstellen Ihrer Nutzercluster keine Passwörter und Dienstkontoschlüssel auf Ihrer Administrator-Workstation aufbewahren müssen.

Sie bereiten Secrets im Administratorcluster im Voraus vor. Wenn Sie dann Nutzercluster erstellen, können Sie festlegen, dass bestimmte Anmeldedaten aus den vorbereiteten Secrets im Administratorcluster übernommen werden. Sie können die vorbereiteten Secrets auch verwenden, wenn Sie Anmeldedaten in einem Nutzercluster rotieren.

Vorbereitung

Erstellen Sie einen Administratorcluster, falls Sie noch keinen haben.

Übersicht über das Verfahren

1. Füllen Sie eine Secret-Konfigurationsdatei aus.

2. Erstellen Sie in Ihrem Administratorcluster Gruppen von Secrets. Jede Secret-Gruppe befindet sich in ihrem eigenen Kubernetes-Namespace.

3. Erstellen Sie einen Nutzercluster. Geben Sie in der Konfigurationsdatei des Nutzerclusters an, dass die Anmeldedaten von Secrets in einem bestimmten Namespace im Administratorcluster übernommen werden sollen.

4. Erstellen Sie je nach Bedarf zusätzliche Secret-Gruppen und zusätzliche Versionen Ihrer Secrets.

5. Aktualisieren Sie nach Bedarf die Anmeldedaten für einen vorhandenen Nutzercluster.

6. Erstellen Sie nach Bedarf weitere Nutzercluster. Geben Sie in jeder Nutzercluster-Konfigurationsdatei einen Secrets-Namespace an. Sie können auch angeben, welche Version eines Secrets Sie für bestimmte Anmeldedaten verwenden möchten.

Secret-Konfigurationsdatei ausfüllen

Vorlage für eine Secrets-Konfigurationsdatei erstellen:

gkectl create-config secrets

Der vorherige Befehl generiert eine Datei mit dem Namen secrets.yaml. Sie können den Namen und den Speicherort dieser Datei bei Bedarf ändern.

Machen Sie sich mit der Konfigurationsdatei vertraut, indem Sie das Dokument Konfigurationsdatei für Secrets lesen. Möglicherweise möchten Sie dieses Dokument in einem separaten Tab oder Fenster geöffnet lassen.

Geben Sie in der Secrets-Konfigurationsdatei die für Ihre Situation relevanten Werte ein. Sie müssen einen Wert für namespace eingeben, der mit gke-onprem-secrets- beginnt.

Hier ist ein Beispiel für eine Secret-Konfigurationsdatei mit einer Secret-Gruppe. Die Gruppe hat Werte für vCenter-Anmeldedaten und vier Dienstkontoschlüssel:

apiVersion: v1
kind: ClusterSecrets
secretGroups:
- namespace: "gke-onprem-secrets-user-cluster-1"
  secrets
    vCenter:
      username: "my-vcenter-account"
      password: "U$icUKEW#INE"
    componentAccessServiceAccount:
      serviceAccountKeyPath: "my-key-folder/component-access-key.json"
    registerServiceAccount:
      serviceAccountKeyPath: "my-key-folder/connect-register-key.json"
    stackdriverServiceAccount:
      serviceAccountKeyPath: "my-key-folder/log-mon-key.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "my-key-folder/audit-log-key.json"

Bereitgestellte Secrets erstellen

Erstellen Sie vorbereitete Secrets in Ihrem Administratorcluster:

gkectl prepare secrets --kubeconfig ADMIN_CLUSTER_KUBECONFIG --secret-config SECRETS_CONFIG

Dabei gilt:

• ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

• SECRETS_CONFIG: der Pfad Ihrer Secrets-Konfigurationsdatei

Bereitgestellte Secrets ansehen

Listen Sie die vorbereiteten Secrets im Administratorcluster auf:

gkectl list secrets --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Beispielausgabe:

The following secrets have been found:
- namespace: gke-onprem-secrets-user-cluster-1
  - secrets with name prefix: component-access-sa-creds
    name: component-access-sa-creds.1, version 1, age: 58s
  - secrets with name prefix: cloud-audit-logging-service-account-creds
    name: cloud-audit-logging-service-account-creds.1, version: 1, age: 58s
  - secrets with name prefix: register-service-account-creds
    name: register-service-account-creds.1, version: 1, age: 58s
  - secrets with name prefix: stackdriver-service-account-creds
    name: stackdriver-service-account-creds.1, version: 1, age: 58s
  - secrets with name prefix: vsphere-creds
    name: vsphere-creds.1, version: 1, age: 58s

Sie können auch kubectl get secrets ausführen, um die Secrets in einem Namespace aufzulisten. Beispiel:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets --namespace gke-onprem-secrets-user-cluster-1

Beispielausgabe:

component-access-sa-creds ...
cloud-audit-logging-service-account-creds ...
register-service-account-creds.1 ...
stackdriver-service-account-creds.1 ...
vsphere-creds.1 ...

In der vorherigen Ausgabe sehen Sie, dass jeder Secret-Name eine Erweiterung hat, die die Version des Secrets angibt. In diesem Beispiel haben alle Secrets die Version  1.

Nutzercluster erstellen

Folgen Sie der Anleitung unter Nutzercluster erstellen.

Geben Sie einen Wert für preparedSecrets.namespace ein, wenn Sie Ihre Nutzercluster-Konfigurationsdatei ausfüllen. Dieser Wert muss mit einem Namespace übereinstimmen, den Sie zuvor in einer Secret-Konfigurationsdatei angegeben haben.

Beispiel:

preparedSecrets:
  namespace: "gke-onprem-secrets-user-cluster-1"

Geben Sie in der Konfigurationsdatei des Nutzerclusters keine Werte für die folgenden Felder an. Diese Felder sind nicht erforderlich, da Google Distributed Cloud die Anmeldedaten und Schlüssel aus Ihren vorbereiteten Secrets erhält.

• vCenter.credentials.fileRef.path
• componentAccessServiceAccountKeyPath
• loadBalancer.f5BigIP.credentials.fileRef.path
• gkeConnect.registerServiceAccountKeyPath
• stackdriver.serviceAccountKeyPath
• usageMetering.bigQueryServiceAccountKeyPath
• cloudAuditLogging.serviceAccountKeyPath
• privateRegistry.credentials.fileRef.path

Geben Sie in der Konfigurationsdatei des Nutzerclusters Versionen für die vorbereiteten Secrets an, die Sie verwenden möchten. Hier ist ein Beispiel, in dem für jedes der fünf Secrets Version 1 angegeben wird:

vCenter:
  credentials:
    secretRef:
      version "1"
...
componentAccessServiceAccountKey:
  secretRef:
    version: "1"
...
gkeConnect:
  registerServiceAccountKey:
    secretRef:
      version: "1"
...
stackdriver:
  serviceAccountKey:
    secretRef:
      version: "1"
...
cloudAuditLogging:
  serviceAccountKey:
    secretRef:
      version: "1"

Der Wert für version muss ein Ganzzahlstring oder der String „latest“ sein. Wenn Sie keinen Wert für version angeben, wird die neueste Version verwendet.

Schließen Sie das Erstellen des Nutzerclusters ab, wie unter Nutzercluster erstellen beschrieben.

Zusätzliche vorbereitete Secrets erstellen

In diesem Abschnitt wird gezeigt, wie Sie Version 2 einiger Secrets in einem vorhandenen Namespace erstellen.

Erstellen Sie eine neue Secrets-Konfigurationsdatei mit dem Namen secrets-2.yaml. Geben Sie einen vorhandenen Namespace an und geben Sie Anmeldedaten für ausgewählte Secrets an.

Beispiel:

apiVersion: v1
kind: ClusterSecrets
secretGroups:
- namespace: "gke-onprem-secrets-user-cluster-1"
  secrets:
    stackdriverServiceAccount:
      serviceAccountKeyPath: "log-mon-sa-2.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "audit-log-sa-2.json"

Das vorherige Beispiel stellt Schlüsselpfade für die folgenden Secrets im Namespace gke-onprem-secrets-user-cluster-1 bereit.

• Version 2 des Secrets stackdriver-service-account-creds
• Version 2 des Secrets cloud-audit-logging-service-account-creds

Erstellen Sie die neuen Secrets:

gkectl prepare secrets --kubeconfig ADMIN_CLUSTER_KUBECONFIG --secret-config secrets-2.yaml

Listen Sie die vorbereiteten Secrets im Administratorcluster auf:

gkectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG list secrets

Beispielausgabe:

The following secrets have been found:
- namespace: gke-onprem-secrets-user-cluster-1
  - secrets with name prefix: component-access-sa-creds
    name: component-access-sa-creds.1, version 1, age: 11h
  - secrets with name prefix: cloud-audit-logging-service-account-creds
    name: cloud-audit-logging-service-account-creds.1, version: 1, age: 11h
    name: cloud-audit-logging-service-account-creds.2, version: 2, age: 33m
  - secrets with name prefix: register-service-account-creds
    name: register-service-account-creds.1, version: 1, age: 11h
  - secrets with name prefix: stackdriver-service-account-creds
    name: stackdriver-service-account-creds.1, version: 1, age: 11h
    name: stackdriver-service-account-creds.2, version: 2, age: 33m
  - secrets with name prefix: vsphere-creds
    name: vsphere-creds.1, version: 1, age: 11h

In der vorherigen Ausgabe sehen Sie, dass es zwei Versionen des Secrets stackdriver-service-account-creds und zwei Versionen des Secrets cloud-audit-logging-service-account-creds gibt.

Anmeldedaten für einen Nutzercluster rotieren

In diesem Abschnitt wird gezeigt, wie Sie ausgewählte Anmeldedaten für einen vorhandenen Nutzercluster rotieren.

Prüfen Sie vor der Rotation der Anmeldeinformationen die aktuellen Secret-Versionen, die im Cluster verwendet werden:

gkectl list secrets cluster --cluster-name USER_CLUSTER_NAME  kubeconfig ADMIN_CLUSTER_KUBECONFIG

Beispielausgabe:

The following prepared secrets have been used for cluster "user-cluster-1":
- namespace: gke-onprem-secrets-user-cluster-1
  secret: vsphere-creds.1, version: 1
  secret: f5-creds.1, version: 1
  secret: component-access-sa-creds.1, version 1
  secret: register-service-account-creds.1, version: 1
  secret: stackdriver-service-account-creds.1, version: 1
  secret: cloud-audit-logging-service-account-creds.1, version: 1

Kopieren Sie die Konfigurationsdatei des Nutzerclusters in eine Datei mit dem Namen user-cluster-update.yaml.

Fügen Sie in user-cluster-update.yaml die Abschnitte serviceAccountKey hinzu. Das folgende Beispiel hat beispielsweise serviceAccountKey-Abschnitte unter stackdriver und cloudAuditLogging:

stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  serviceAccountKey:
    secretRef:
      version: "2"
cloudAuditLogging:
  projectID: "my-project-123"
  clusterLocation: "us-central-1"
  serviceAccountKey:
    secretRef:
      version: "latest"

Das vorherige Beispiel gibt an, dass bei der Aktualisierung des Nutzerclusters Folgendes verwendet wird:

• Version 2 des Secrets stackdriver-service-account-creds

• Die neueste Version des cloud-audit-logging-service-account-creds-Secrets. In diesem Beispiel ist das Version 2.

Hinweis: Wenn Sie ein Secret aktualisieren, muss der für secretRef.version angegebene Wert „latest” oder ein ganzzahliger String sein. Sie können secretRef.version nicht weglassen und nicht auf einen leeren String festlegen.

Aktualisieren Sie die Anmeldedaten für den Nutzercluster:

gkectl update credentials stackdriver --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config user-cluster-2.yaml

gkectl update credentials cloudauditlogging --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config user-cluster-2.yaml

Jetzt verwendet der Nutzercluster die folgenden vorbereiteten Secrets:

• Version 1 von vsphere-creds
• Version 1 von component-access-sa-creds
• Version 1 von register-service-account-creds
• Version 2 von stackdriver-service-account-creds
• Version 2 von cloud-audit-logging-service-account-creds

Zusätzliche Secrets und Nutzercluster erstellen

Wenn Sie zusätzliche Nutzercluster erstellen möchten, sollten Sie überlegen, wie Sie Ihre vorbereiteten Secrets organisieren möchten. Sie können in Ihrem Administratorcluster einen separaten Namespace für jeden Nutzercluster erstellen. Oder Sie möchten denselben vorbereiteten Secret-Namespace für mehrere oder alle Nutzercluster freigeben.

Angenommen, Alice, Bob und Carol haben jeweils einen Nutzercluster. Sie können drei Secret-Gruppen erstellen, wie in diesem Beispiel gezeigt:

apiVersion: v1
kind: ClusterSecrets
secretGroups:
- namespace: "gke-onprem-secrets-alice"
  secrets:
    vCenter:
      username: "alice"
      password: "zC7r^URDPq2t"
    componentAccessServiceAccount:
      serviceAccountKeyPath: "component-access-sa-a.json"
    registerServiceAccount:
      serviceAccountKeyPath: "register-sa-a.json"
    stackdriverServiceAccount:
      serviceAccountKeyPath: "log-mon-sa-a.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "audit-log-sa-a.json"
- namespace: "gke-onprem-secrets-bob"
  secrets:
    vCenter:
      username: "bob"
      password: "zC8r^URDPq2t"
    componentAccessServiceAccount:
      serviceAccountKeyPath: "component-access-sa-b.json"
    registerServiceAccount:
      serviceAccountKeyPath: "register-sa-b.json"
    stackdriverServiceAccount:
      serviceAccountKeyPath: "log-mon-sa-b.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "audit-log-sa-b.json"
- namespace: "gke-onprem-secrets-carol"
  secrets:
    vCenter:
      username: "carol"
      password: "zC9r^URDPq2t"
    componentAccessServiceAccount:
      serviceAccountKeyPath: "component-access-sa-c.json"
    registerServiceAccount:
      serviceAccountKeyPath: "register-sa-c.json"
    stackdriverServiceAccount:
      serviceAccountKeyPath: "log-mon-sa-c.json"
    cloudAuditLoggingServiceAccount:
      serviceAccountKeyPath: "audit-log-sa-c.json"

Mit der Zeit können Sie in jeder Secret-Gruppe zusätzliche Versionen der Secrets erstellen.

Geben Sie in den Nutzercluster-Konfigurationsdateien Werte für serviceAccountKey.secretRef.version an, um anzugeben, welche Versionen Ihrer Secrets Sie verwenden möchten. Sie können den Wert auf "latest", den leeren String oder einen Ganzzahlstring festlegen.

Angenommen, alle Secrets haben die Versionen 1, 2 und 3. Nehmen wir außerdem an, dass dies ein Teil der Nutzercluster-Konfigurationsdatei für Alice ist.

apiVersion: v1
kind: UserCluster
name: "user-cluster-alice"
preparedSecrets:
  namespace: "gke-onprem-secrets-alice"
...
vCenter:
  credentials:
gkeConnect:
  projectID: "project-a"
  serviceAccountKey:
    secretRef:
      version: "2"
stackdriver:
  projectID: "project-a"
  clusterLocation: "us-central1"
  serviceAccountKey:
    secretRef:
      version: "latest"
cloudAuditLogging:
  projectID: "project-a"
  clusterLocation: "us-central-1"
  serviceAccountKey:
    secretRef:
      version: ""

Im vorherigen Beispiel ist Folgendes zu sehen:

• Es ist kein secretRef für vCenter angegeben, sodass der Cluster die neueste Version des vsphere-creds-Secrets im Namespace gke-onprem-secrets-alice verwendet.

• Der Cluster verwendet Version 2 des Secrets register-service-account-creds im Namespace gke-onprem-secrets-alice.

• Der Cluster verwendet die neueste Version des Secrets stackdriver-service-account-creds im Namespace gke-onprem-secrets-alice. In diesem Beispiel ist das Version 3.

• Die Version für cloudAuditLogging ist der leere String, sodass der Cluster die neueste Version des cloud-audit-logging-service-account-creds-Secrets im gke-onprem-secrets-alice-Namespace ist. In diesem Beispiel ist das Version 3.

• Es ist kein secretRef.version für das Dienstkonto für den Komponentenzugriff angegeben, sodass der Cluster die neueste Version verwendet.

Vorbereitete Secrets löschen

So listen Sie alle vorbereiteten Secrets und deren Namespaces auf:

gkectl list secrets --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Wenn ein vorbereiteter Secret-Namespace von keinem Nutzercluster verwendet wird, können Sie ihn löschen.

So löschen Sie einen vorbereiteten Secret-Namespace und alle darin enthaltenen Secrets:

gkectl delete secret –namespace PREPARED_SECRET_NAMESPACE \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Wenn ein einzelnes vorbereitetes Secret von keinem Nutzercluster verwendet wird, können Sie es löschen.

So löschen Sie ein einzelnes vorbereitetes Secret:

gkectl delete secret –namespace PREPARED_SECRET_NAMESPACE \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --secret-name SECRET

Zugehörige Dokumente

• Konfigurationsdatei für Secrets
• Konfigurationsdatei für den Nutzerclusters
• Nutzercluster erstellen
• Dienstkonten erstellen