Clusterauthentifizierung mit Workload Identity

Mit der Workload Identity-Clusterauthentifizierung können Sie Cluster für Distributed Cloud-Software nur für Bare Metal erstellen und sichern. Dazu verwenden Sie kurzlebige Tokens und die Workload Identity-Föderation. Bei diesem Ansatz werden nichtflüchtige Dienstkontoschlüssel durch OAuth 2.0-Zugriffstokens ersetzt. Dadurch wird der Wartungsaufwand reduziert und die Sicherheitsrisiken langlebiger Anmeldedaten werden eliminiert.

Sie können diese Funktion nur beim Erstellen neuer Cluster aktivieren. Dieses Feature ist in Version 1.33 und höher sowie in der Vorabversion in den Versionen 1.30, 1.31 und 1.32 verfügbar. Sie können vorhandene Cluster nicht aktualisieren, um sie zu verwenden. Weitere Einschränkungen finden Sie unter Einschränkungen.

Funktionsweise der Workload Identity-Clusterauthentifizierung

Die kurzlebigen Anmeldedaten für das Dienstkonto haben die Form von OAuth 2.0-Zugriffstokens. Die Zugriffstokens laufen standardmäßig nach einer Stunde ab. Ebenso laufen Image-Pull-Tokens standardmäßig nach einer Stunde ab.

Im Gegensatz dazu werden im Schlüsselmodus, der Standardmethode zum Erstellen und Sichern von Clustern, heruntergeladene Dienstkontoschlüssel verwendet. Wenn Sie einen selbstverwalteten Cluster (Administrator-, Hybrid- oder eigenständigen Cluster) erstellen, geben Sie den Pfad zu den heruntergeladenen Schlüsseln an. Die Schlüssel werden dann als Secrets im Cluster und in allen verwalteten Nutzerclustern gespeichert. Standardmäßig laufen Dienstkontoschlüssel nicht ab und stellen ein Sicherheitsrisiko dar, wenn sie nicht ordnungsgemäß verwaltet werden. Informationen zum Festlegen einer Ablaufzeit für Ihre Dienstkontoschlüssel finden Sie unter Ablaufzeiten für von Nutzern verwaltete Schlüssel.

Die Clusterauthentifizierung mit Workload Identity bietet zwei wesentliche Vorteile gegenüber der Verwendung von Dienstkontoschlüsseln:

  • Verbesserte Sicherheit: Dienstkontoschlüssel stellen ein Sicherheitsrisiko dar, wenn sie nicht ordnungsgemäß verwaltet werden. OAuth 2.0-Tokens und die Workload Identity-Föderation gelten als Best-Practice-Alternativen zu Dienstkontoschlüsseln. Weitere Informationen zu Dienstkonto-Tokens finden Sie unter Kurzlebige Anmeldedaten für Dienstkonten. Weitere Informationen zur Identitätsföderation von Arbeitslasten finden Sie unter Identitätsföderation von Arbeitslasten.

  • Weniger Wartungsaufwand: Dienstkontoschlüssel erfordern mehr Wartung. Das regelmäßige Rotieren und Sichern dieser Schlüssel kann einen erheblichen Verwaltungsaufwand bedeuten.

Hinweis

In den folgenden Abschnitten erstellen Sie Dienstkonten und weisen Rollen zu, die für die Workload Identity-Clusterauthentifizierung erforderlich sind. Die Einrichtungsanleitung in diesem Dokument ersetzt nicht die Anleitung unter Google Cloud-Ressourcen einrichten. Sie ist zusätzlich zu den Standardvoraussetzungen für die Installation der Distributed Cloud-Software erforderlich. Die für die Workload Identity-Clusterauthentifizierung erforderlichen Dienstkonten ähneln den Dienstkonten, die unter Google Cloud -Ressourcen einrichten beschrieben werden. Sie haben jedoch eindeutige Namen, sodass sie nicht mit Clustern in Konflikt geraten, die die Standarddienstkontoschlüssel verwenden.

Die für die Workload Identity-Clusterauthentifizierung erforderlichen Dienstkonten unterscheiden sich für die Vorabversion und die GA-Angebote, wie in der folgenden Tabelle beschrieben:

1.33 und höher

Dienstkonto Zweck Rollen
admin-sa Sie verwenden dieses Dienstkonto, um Tokens zu generieren. Jedes Token hat die Berechtigungen, die mit den Dienstkontorollen verknüpft sind. roles/gkehub.admin
roles/iam.serviceAccountAdmin
roles/iam.serviceAccountTokenCreator
roles/iam.workloadIdentityPoolAdmin*
roles/logging.admin
roles/monitoring.admin
roles/resourcemanager.projectIamAdmin
baremetal-gcr Google Distributed Cloud verwendet dieses Dienstkonto, um Container-Images aus Artifact Registry herunterzuladen. Keine

*Die IAM-Rolle roles/iam.workloadIdentityPoolAdmin ist nur für Version 1.34 und höher erforderlich.

1.30-1.32

Dienstkonto Zweck Rollen
admin-sa Sie verwenden dieses Dienstkonto, um Tokens zu generieren. Jedes Token hat die Berechtigungen, die mit den Dienstkontorollen verknüpft sind. roles/gkehub.admin
roles/iam.serviceAccountAdmin
roles/iam.serviceAccountTokenCreator
roles/logging.admin
roles/monitoring.admin
baremetal-controller Connect Agent verwendet dieses Dienstkonto, um eine Verbindung zwischen Ihrem Cluster und Google Cloud aufrechtzuerhalten und Ihre Cluster bei einer Flotte zu registrieren. Dieses Dienstkonto aktualisiert auch Tokens für das Dienstkonto baremetal-gcr. roles/gkehub.admin
roles/monitoring.dashboardEditor
roles/serviceusage.serviceUsageViewer
baremetal-cloud-ops Stackdriver Agent verwendet dieses Dienstkonto, um Logs und Messwerte von Clustern nach Cloud Logging und Cloud Monitoring zu exportieren. roles/kubernetesmetadata.publisher
roles/logging.logWriter
roles/monitoring.dashboardEditor
roles/monitoring.metricWriter
roles/monitoring.viewer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/serviceusage.serviceUsageViewer
roles/stackdriver.resourceMetadata.writer
baremetal-gcr Google Distributed Cloud verwendet dieses Dienstkonto, um Container-Images aus Artifact Registry herunterzuladen. Keine

Dienstkonten einrichten

In den folgenden Abschnitten finden Sie eine Anleitung zum Erstellen der erforderlichen Dienstkonten und zum Zuweisen der erforderlichen Rollen für die Workload Identity-Clusterauthentifizierung. Eine Liste der Dienstkonten und ihrer erforderlichen Rollen finden Sie in der Tabelle im vorherigen Abschnitt.

Dienstkonten erstellen

So erstellen Sie die Dienstkonten für die Workload Identity-Clusterauthentifizierung:

  1. Melden Sie sich auf Ihrer Administrator-Workstation in der Google Cloud CLI an:

    gcloud auth login
    
  2. Erstellen Sie die erforderlichen Dienstkonten für die Workload Identity-Clusterauthentifizierung:

    Der Name des Dienstkontos admin-sa ist beliebig. Sie können den Namen ändern, wenn er einen Konflikt in Ihrem Projekt verursacht. Die anderen Dienstkonten für die Workload Identity-Clusterauthentifizierung haben vordefinierte Namen, die Sie bei Bedarf anpassen können.

    1.33 und höher

    gcloud iam service-accounts create admin-sa \
        --project=PROJECT_ID
    
    gcloud iam service-accounts create baremetal-gcr \
        --project=PROJECT_ID
    

    Ersetzen Sie PROJECT_ID durch die ID Ihres Projekts vonGoogle Cloud .

    1.30-1.32

    ```sh gcloud iam service-accounts create admin-sa
    --project=PROJECT_ID

    gcloud iam service-accounts create baremetal-controller
    --project=PROJECT_ID

    gcloud iam service-accounts create baremetal-cloud-ops
    --project=PROJECT_ID

    gcloud iam service-accounts create baremetal-gcr
    --project=PROJECT_ID ```

    Ersetzen Sie PROJECT_ID durch die ID Ihres Projekts vonGoogle Cloud .

Identity and Access Management-Richtlinienbindungen für Dienstkonten hinzufügen

So wenden Sie die erforderlichen Identity and Access Management-Richtlinienbindungen auf die neuen Dienstkonten an:

1.33 und höher

  1. Fügen Sie IAM-Richtlinienbindungen für erforderliche Rollen für das Dienstkonto admin-sa hinzu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/gkehub.admin
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/iam.serviceAccountAdmin
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/iam.serviceAccountTokenCreator
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/logging.admin
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/monitoring.admin
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/resourcemanager.projectIamAdmin
    

1.30-1.32

  1. Fügen Sie IAM-Richtlinienbindungen für erforderliche Rollen für das Dienstkonto admin-sa hinzu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/gkehub.admin
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/iam.serviceAccountAdmin
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/iam.serviceAccountTokenCreator
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/logging.admin
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/monitoring.admin
    
  2. Fügen Sie IAM-Richtlinienbindungen für erforderliche Rollen für das Dienstkonto baremetal-controller hinzu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/gkehub.admin
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/monitoring.dashboardEditor
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/serviceusage.serviceUsageViewer
    
  3. Fügen Sie IAM-Richtlinienbindungen für erforderliche Rollen für das Dienstkonto baremetal-cloud-ops hinzu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/kubernetesmetadata.publisher
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/logging.logWriter
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/monitoring.dashboardEditor
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/monitoring.metricWriter
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/monitoring.viewer
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/opsconfigmonitoring.resourceMetadata.writer
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/serviceusage.serviceUsageViewer
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/stackdriver.resourceMetadata.writer
    
  4. Gewähren Sie dem Dienstkonto baremetal-controller die Möglichkeit, Zugriffstokens im Namen des Dienstkontos baremetal-gcr zu generieren:

    gcloud iam service-accounts add-iam-policy-binding \
        baremetal-gcr@PROJECT_ID.iam.gserviceaccount.com \
        --member=serviceAccount:baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
        --role=roles/iam.serviceAccountTokenCreator
    

Authentifizierung einrichten

In den folgenden Schritten wird der Authentifizierungsablauf eingerichtet, bei dem ein kurzlebiges Token zur Authentifizierung von Clustervorgängen verwendet wird:

  1. Melden Sie sich auf Ihrer Administrator-Workstation in der Google Cloud CLI an:

    gcloud auth login
    
  2. Erstellen Sie auf Ihrer Administrator-Workstation einen Schlüssel für das Dienstkonto admin-sa und laden Sie ihn herunter:

    Dieser Schlüssel ist erforderlich, um den Zugriff für das Dienstkonto admin-sa zu autorisieren.

    gcloud iam service-accounts keys create TMP_KEY_FILE_PATH \
        --iam-account=admin-sa@PROJECT_ID.iam.gserviceaccount.com
    

    Ersetzen Sie TMP_KEY_FILE_PATH durch den Pfad, einschließlich des Dateinamens, der heruntergeladenen Schlüsseldatei.

  3. Erstellen Sie auf Ihrer Administrator-Workstation eine Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS mit dem Wert des heruntergeladenen Dienstkontoschlüssels:

    export GOOGLE_APPLICATION_CREDENTIALS=TMP_KEY_FILE_PATH
    
  4. Erstellen Sie auf Ihrer Administrator-Workstation eine Umgebungsvariable GCP_ACCESS_TOKEN mit dem Wert eines Zugriffstokens, das vom Dienstkonto admin-sa erstellt wurde:

    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)
    

    Standardmäßig hat das Zugriffstoken eine Lebensdauer von 1 Stunde.

  5. Prüfen Sie, ob das Token vom Dienstkonto admin-sa mit dem richtigen Ablaufdatum generiert wurde:

    curl "https://oauth2.googleapis.com/tokeninfo?access_token=$GCP_ACCESS_TOKEN"
    

    Die Antwort sollte in etwa so aussehen:

    ...
    "exp": "1759512810",
    "expires_in": "3589",
    ...
    

    Der Ablaufwert wird in Sekunden angegeben und sollte kleiner als 3600 sein, was bedeutet, dass das Token in weniger als einer Stunde abläuft.

Workload Identity-Föderation für Ihre Cluster konfigurieren

Um Zugriff auf Google Cloud über die Identitätsföderation von Arbeitslasten für GKE zu gewähren, erstellen Sie eine IAM-Zulassungsrichtlinie, die einem Hauptkonto Zugriff auf eine bestimmteGoogle Cloud -Ressource gewährt, das der Identität Ihrer Anwendung entspricht. In diesem Fall gewährt die Workload Identity-Föderation Zugriff auf bestimmte Operatoren im Cluster. Weitere Informationen zu Workload Identity Federation for GKE finden Sie unter Identitätsföderation von Arbeitslasten in der IAM-Dokumentation.

1.33 und höher

Für Clusterversionen, in denen die Workload Identity-Clusterauthentifizierung allgemein verfügbar ist, verwenden Sie den Befehl bmctl configure projects, um die Workload Identity-Föderation für Ihre Cluster zu konfigurieren. Dieser Befehl ist in die Schritte zum Erstellen eines Administratorclusters und zum Erstellen eines Nutzerclusters eingebunden.

Wenn Sie eine Registry-Spiegelung verwenden, um Container-Images für Ihren Cluster abzurufen, müssen Sie die Clusterannotation baremetal.cluster.gke.io/enable-gcr-image-credential-refresh: "false" hinzufügen, um Instabilität von containerd zu verhindern. Diese Annotation ist für die Versionen 1.33.200-gke.70 und höher verfügbar:

---
...
registryMirrors:
  - endpoint: https://198.51.20.1:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
    hosts:
      - somehost.io
      - otherhost.io
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
  annotations:
    baremetal.cluster.gke.io/enable-gcr-image-credential-refresh: "false"
spec:
  type: admin
  anthosBareMetalVersion: 1.33.200-gke.70
  ...

1.30-1.32

Bei Clusterversionen, in denen sich die Workload Identity-Clusterauthentifizierung in der Vorschau befindet, müssen Sie die Workload Identity-Föderation für Ihre Cluster manuell konfigurieren, wie in den folgenden Abschnitten beschrieben.

IAM-Richtlinienbindungen für den Clusteroperator hinzufügen

Mit den folgenden Befehlen wird dem Kubernetes-Dienstkonto anthos-cluster-operator die Möglichkeit gewährt, die Identität des Dienstkontos baremetal-controller zu übernehmen und im Namen des Clusters mit Google Cloud -Ressourcen zu interagieren:

  1. Gewähren Sie für jeden Cluster, der für die Workload Identity-Clusterauthentifizierung konfiguriert ist (oder für den die Verwendung der Workload Identity-Clusterauthentifizierung geplant ist), einschließlich des Bootstrap-Clusters, anthos-cluster-operator im Cluster die Möglichkeit, die Identität des Dienstkontos baremetal-controller zu übernehmen:

    Im folgenden Befehl besteht principalSet aus dem Workload Identity-Pool und einem Kubernetes-Dienstkonto anthos-cluster-operator im Namespace kube-system.

    gcloud iam service-accounts add-iam-policy-binding \
        baremetal-controller@PROJECT_ID.iam.gserviceaccount.com \
        --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/anthos-cluster-operator \
        --role=roles/iam.workloadIdentityUser \
        --project=PROJECT_ID
    

    Ersetzen Sie Folgendes:

    • PROJECT_NUM: die automatisch generierte eindeutige Kennung für Ihr Projekt.

    • REGION: der Standort der Flottenmitgliedschaft für Ihren Cluster, standardmäßig global. Weitere Informationen finden Sie unter Standort der Flottenmitgliedschaft.

    • CLUSTER_NAME ist der Name des Clusters. Standardmäßig lautet der Name des Bootstrap-Clusters bmctl-MACHINE_NAME.

  2. Prüfen Sie die Richtlinienbindungen für das Dienstkonto baremetal-controller:

    gcloud iam service-accounts get-iam-policy \
        baremetal-controller@PROJECT_ID.iam.gserviceaccount.com
    

    Die Antwort sollte in etwa so aussehen:

    bindings:
    - members:
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/anthos-cluster-operator
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/anthos-cluster-operator
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/anthos-cluster-operator
      role: roles/iam.workloadIdentityUser
    etag: BwYoN3QLig0=
    version: 1
    

IAM-Richtlinienbindungen für die Google Cloud Observability-Operatoren hinzufügen

Mit den folgenden Befehlen wird den folgenden Kubernetes-Dienstkonten von Google Cloud Observability die Möglichkeit gewährt, die Identität des Dienstkontos baremetal-cloud-ops zu übernehmen und im Namen des Clusters mit Google Cloud -Ressourcen zu interagieren:

  • cloud-audit-logging
  • gke-metrics-agent
  • kubestore-collector
  • metadata-agent
  • stackdriver-log-forwarder
  1. Gewähren Sie für jeden Cluster, der für die Workload Identity-Clusterauthentifizierung konfiguriert ist (oder für den die Verwendung der Workload Identity-Clusterauthentifizierung geplant ist), einschließlich des Bootstrap-Clusters, den Google Cloud Observability-Operatoren im Cluster die Möglichkeit, die Identität des Dienstkontos baremetal-cloud-ops zu übernehmen:

    In jedem der folgenden Befehle besteht das principalSet aus dem Workload Identity-Pool und einem Kubernetes-Dienstkonto, z. B. cloud-audit-logging, im Namespace kube-system.

    gcloud iam service-accounts add-iam-policy-binding \
        baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/cloud-audit-logging \
        --role=roles/iam.workloadIdentityUser \
        --project=PROJECT_ID
    
    gcloud iam service-accounts add-iam-policy-binding \
        baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/gke-metrics-agent \
        --role=roles/iam.workloadIdentityUser \
        --project=PROJECT_ID
    
    gcloud iam service-accounts add-iam-policy-binding \
        baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/kubestore-collector \
        --role=roles/iam.workloadIdentityUser \
        --project=PROJECT_ID
    
    gcloud iam service-accounts add-iam-policy-binding \
        baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/metadata-agent \
        --role=roles/iam.workloadIdentityUser \
        --project=PROJECT_ID
    
    gcloud iam service-accounts add-iam-policy-binding \
        baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com \
        --member=principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/attribute.fleetclusteridentity/projects/PROJECT_ID/locations/REGION/memberships/CLUSTER_NAME/ns/kube-system/sa/stackdriver-log-forwarder \
        --role=roles/iam.workloadIdentityUser \
        --project=PROJECT_ID
    
  2. Prüfen Sie die Richtlinienbindungen für das Dienstkonto baremetal-cloud-ops:

    gcloud iam service-accounts get-iam-policy \
        baremetal-cloud-ops@PROJECT_ID.iam.gserviceaccount.com
    

    Die Antwort sollte in etwa so aussehen:

    bindings:
    - members:
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/cloud-audit-logging
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/gke-metrics-agent
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/kubestore-collector
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/metadata-agent
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/bmctl-admin-ws/kube-system/stackdriver-log-forwarder
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/cloud-audit-logging
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/gke-metrics-agent
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/kubestore-collector
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/metadata-agent
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/admin-cluster/kube-system/stackdriver-log-forwarder
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/cloud-audit-logging
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/gke-metrics-agent
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/kubestore-collector
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/metadata-agent
      - principalSet://iam.googleapis.com/projects/112233445566/locations/global/workloadIdentityPools/my-project.svc.id.goog/attribute.fleetclusteridentity/user-cluster/kube-system/stackdriver-log-forwarder
      role: roles/iam.workloadIdentityUser
    etag: BwYhT4gL-dY=
    version: 1
    

Administratorcluster erstellen

Die Schritte zum Erstellen eines Administratorclusters unterscheiden sich geringfügig für die Vorabversion (Versionen 1.30–1.32) und die GA-Version (Versionen 1.33 und höher). In den GA-Schritten wird der Befehl bmctl configure projects verwendet, um die Workload Identity-Föderation für Ihre Cluster zu konfigurieren.

1.33 und höher

Der offensichtlichste Unterschied bei der Clusterkonfiguration für Cluster, die die Workload Identity-Clusterauthentifizierung verwenden, besteht darin, dass Sie keine Pfade zu heruntergeladenen Dienstkontoschlüsseln angeben.

  1. Wenn Sie die Clustereinstellungen in der Konfigurationsdatei ausfüllen, lassen Sie die Dienstkontoschlüsselpfade im Abschnitt „Anmeldedaten“ leer, wie im folgenden Beispiel gezeigt:

    gcrKeyPath:
    sshPrivateKeyPath: /home/USERNAME/.ssh/id_rsa
    gkeConnectAgentServiceAccountKeyPath:
    gkeConnectRegisterServiceAccountKeyPath:
    cloudOperationsServiceAccountKeyPath:
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-ADMIN_CLUSTER_NAME
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: ADMIN_CLUSTER_NAME
      namespace: cluster-ADMIN_CLUSTER_NAME
    spec:
      type: admin
      profile: default
      anthosBareMetalVersion: 1.33.0-gke.799
      ...
    
  2. Fügen Sie die Annotation baremetal.cluster.gke.io/enable-workload-identity-cluster-authentication: "true" zur Clusterkonfigurationsdatei hinzu:

    gcrKeyPath:
    sshPrivateKeyPath: /home/USERNAME/.ssh/id_rsa
    gkeConnectAgentServiceAccountKeyPath:
    gkeConnectRegisterServiceAccountKeyPath:
    cloudOperationsServiceAccountKeyPath:
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-ADMIN_CLUSTER_NAME
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: ADMIN_CLUSTER_NAME
      namespace: cluster-ADMIN_CLUSTER_NAME
      annotations:
        baremetal.cluster.gke.io/enable-workload-identity-cluster-authentication: "true"
    spec:
      type: admin
      profile: default
      anthosBareMetalVersion: 1.33.0-gke.799
      ...
    
  3. Aktualisieren Sie auf Ihrer Administrator-Workstation die Umgebungsvariable GCP_ACCESS_TOKEN mit einem neu abgerufenen Zugriffstoken:

    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)
    

    Standardmäßig hat das Zugriffstoken eine Lebensdauer von 3.600 Sekunden (1 Stunde). Wenn Sie die Workload Identity-Clusterauthentifizierung verwenden, prüft bmctl die Ablaufzeit des Tokens. Wenn das Token innerhalb von 1.800 Sekunden (30 Minuten) abläuft, meldet bmctl einen Fehler und wird beendet.

  4. Konfigurieren Sie die Identitätsföderation von Arbeitslasten für den Cluster, den Sie erstellen:

    bmctl configure projects --project-id=PROJECT_ID \
        --admin-cluster=ADMIN_CLUSTER_NAME
    
  5. Führen Sie den Befehl bmctl create cluster aus, um den Administratorcluster zu erstellen.

1.30-1.32

Der offensichtlichste Unterschied bei der Clusterkonfiguration für Cluster, die die Workload Identity-Clusterauthentifizierung verwenden, besteht darin, dass Sie keine Pfade zu heruntergeladenen Dienstkontoschlüsseln angeben.

  1. Wenn Sie die Clustereinstellungen in der Konfigurationsdatei ausfüllen, lassen Sie die Pfade für die Dienstkontoschlüssel im Abschnitt „Anmeldedaten“ leer, wie im folgenden Beispiel gezeigt:

    gcrKeyPath:
    sshPrivateKeyPath: /home/USERNAME/.ssh/id_rsa
    gkeConnectAgentServiceAccountKeyPath:
    gkeConnectRegisterServiceAccountKeyPath:
    cloudOperationsServiceAccountKeyPath:
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-ADMIN_CLUSTER_NAME
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: ADMIN_CLUSTER_NAME
      namespace: cluster-ADMIN_CLUSTER_NAME
    spec:
      type: admin
      profile: default
      anthosBareMetalVersion: 1.33.0-gke.799
      ...
    
  2. Erstellen Sie auf Ihrer Administrator-Workstation einen Schlüssel für das Dienstkonto admin-sa und laden Sie ihn herunter:

    Dieser Schlüssel ist erforderlich, um den Zugriff für das Dienstkonto admin-sa zu autorisieren. Sie löschen ihn sofort, nachdem das Dienstkonto autorisiert wurde.

    gcloud iam service-accounts keys create TMP_KEY_FILE_PATH \
        --iam-account=admin-sa@PROJECT_ID.iam.gserviceaccount.com
    

    Ersetzen Sie TMP_KEY_FILE_PATH durch den Pfad, einschließlich des Dateinamens, der heruntergeladenen Schlüsseldatei.

  3. Autorisieren Sie den Zugriff auf Google Cloud mit dem Dienstkonto admin-sa:

    gcloud auth activate-service-account admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --key-file=TMP_KEY_FILE_PATH
    
  4. Löschen Sie die heruntergeladene JSON-Schlüsseldatei:

    rm TMP_KEY_FILE_PATH
    

    Das Zugriffstoken ist kurzlebig. Daher müssen Sie es in der Regel neu generieren, bevor Sie bmctl-Befehle für Clustervorgänge wie das Erstellen, Aktualisieren oder Zurücksetzen eines Clusters ausführen.

  5. Erstellen Sie auf Ihrer Administrator-Workstation eine Umgebungsvariable GCP_ACCESS_TOKEN mit dem Wert eines Zugriffstokens, das vom Dienstkonto admin-sa erstellt wurde:

    export GCP_ACCESS_TOKEN=$(gcloud auth print-access-token \
        --impersonate-service-account=admin-sa@PROJECT_ID.iam.gserviceaccount.com)
    

    Standardmäßig hat das Zugriffstoken eine Lebensdauer von 3.600 Sekunden (1 Stunde).

  6. Führen Sie den Befehl bmctl create cluster aus, um den Administratorcluster zu erstellen.

Nutzercluster erstellen

Die Schritte zum Erstellen eines Administratorclusters unterscheiden sich geringfügig für die Vorabversion (Versionen 1.30–1.32) und die GA-Version (Versionen 1.33 und höher). In den GA-Schritten wird der Befehl bmctl configure projects verwendet, um die Workload Identity-Föderation für Ihre Cluster zu konfigurieren.

1.33 und höher

  1. Fügen Sie die Annotation baremetal.cluster.gke.io/enable-workload-identity-cluster-authentication: "true" zur Clusterkonfigurationsdatei hinzu:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-USER_CLUSTER_NAME
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: USER_CLUSTER_NAME
      namespace: cluster-USER_CLUSTER_NAME
      annotations:
        baremetal.cluster.gke.io/enable-workload-identity-cluster-authentication: "true"
    spec:
      type: admin
      profile: default
      anthosBareMetalVersion: 1.33.0-gke.799
      ...
    

    Das Zugriffstoken ist kurzlebig. Daher müssen Sie es in der Regel neu generieren, bevor Sie bmctl-Befehle für Clustervorgänge wie das Erstellen, Aktualisieren oder Zurücksetzen eines Clusters ausführen.

  2. Aktualisieren Sie auf Ihrer Administrator-Workstation die Umgebungsvariable GCP_ACCESS_TOKEN mit einem neu abgerufenen Zugriffstoken:

    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)
    

    Standardmäßig hat das Zugriffstoken eine Lebensdauer von 3.600 Sekunden (1 Stunde).

  3. Konfigurieren Sie die Identitätsföderation von Arbeitslasten für den Cluster, den Sie erstellen:

    bmctl configure projects --project-id=PROJECT_ID \
        --user-clusters=USER_CLUSTER_NAME
    
  4. Verwenden Sie kubectl, um das Nutzercluster-Manifest bereitzustellen:

    kubectl apply -f USER_CLUSTER_CONFIG \
        --kubeconfig ADMIN_KUBECONFIG
    

Ersetzen Sie Folgendes:

  • USER_CLUSTER_CONFIG: der Pfad der Nutzercluster-Konfigurationsdatei.

  • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters.

1.30-1.32

  1. Erstellen Sie auf Ihrer Administrator-Workstation einen Schlüssel für das Dienstkonto admin-sa und laden Sie ihn herunter:

    Dieser Schlüssel ist erforderlich, um den Zugriff für das Dienstkonto admin-sa zu autorisieren. Sie löschen ihn sofort, nachdem das Dienstkonto autorisiert wurde.

    gcloud iam service-accounts keys create TMP_KEY_FILE_PATH \
        --iam-account=admin-sa@PROJECT_ID.iam.gserviceaccount.com
    

    Ersetzen Sie TMP_KEY_FILE_PATH durch den Pfad, einschließlich des Dateinamens, der heruntergeladenen Schlüsseldatei.

  2. Autorisieren Sie den Zugriff auf Google Cloud mit dem Dienstkonto admin-sa:

    gcloud auth activate-service-account admin-sa@PROJECT_ID.iam.gserviceaccount.com \
        --key-file=TMP_KEY_FILE_PATH
    
  3. Löschen Sie die heruntergeladene JSON-Schlüsseldatei:

    rm TMP_KEY_FILE_PATH
    

    Das Zugriffstoken ist kurzlebig. Daher müssen Sie es in der Regel neu generieren, bevor Sie bmctl-Befehle für Clustervorgänge wie das Erstellen, Aktualisieren oder Zurücksetzen eines Clusters ausführen.

  4. Erstellen Sie auf Ihrer Administrator-Workstation eine Umgebungsvariable GCP_ACCESS_TOKEN mit dem Wert eines Zugriffstokens, das vom Dienstkonto admin-sa erstellt wurde:

    export GCP_ACCESS_TOKEN=$(gcloud auth print-access-token \
        --impersonate-service-account=admin-sa@PROJECT_ID.iam.gserviceaccount.com)
    

    Standardmäßig hat das Zugriffstoken eine Lebensdauer von 3.600 Sekunden (1 Stunde).

  5. Führen Sie den Befehl bmctl create cluster aus, um den Nutzercluster zu erstellen.

Andere Clustervorgänge

Bei Clustern, die die Workload Identity-Clusterauthentifizierung verwenden, müssen Sie für die folgenden bmctl-Befehle die Umgebungsvariable GCP_ACCESS_TOKEN auf ein gültiges, aktives Zugriffstoken festlegen:

  • bmctl configure projects
  • bmctl create cluster
  • bmctl register bootstrap
  • bmctl reset cluster
  • bmctl upgrade cluster

bmctl register bootstrap unterstützt die Verwendung der Umgebungsvariable GCP_ACCESS_TOKEN für die Workload Identity-Clusterauthentifizierung nur für Google Distributed Cloud ab Version 1.34.0. Für Versionen vor 1.34.0 müssen Sie Dienstkonto-Schlüsseldateien verwenden, um bmctl register bootstrap zu authentifizieren.

Wenn bmctl erkennt, dass die Umgebungsvariable GCP_ACCESS_TOKEN festgelegt wurde, wird eine Tokenvalidierung durchgeführt:

  • Wenn das Token gültig ist, wird es von bmctl für Clustervorgänge verwendet.

  • Wenn das Token nicht gültig ist, rufen Sie ein neues ab:

    Das Zugriffstoken ist kurzlebig. Daher müssen Sie es in der Regel neu generieren, bevor Sie bmctl-Befehle für Clustervorgänge wie das Erstellen, Aktualisieren oder Zurücksetzen eines Clusters ausführen. Aktualisieren Sie auf Ihrer Administrator-Workstation die Umgebungsvariable GCP_ACCESS_TOKEN mit einem neu abgerufenen Zugriffstoken:

    1.33 und höher

    export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token)
    

    1.30-1.32

    sh export GCP_ACCESS_TOKEN=$(gcloud auth print-access-token \ --impersonate-service-account=admin-sa@PROJECT_ID.iam.gserviceaccount.com)

    Standardmäßig hat das Zugriffstoken eine Lebensdauer von 3.600 Sekunden (1 Stunde). Wenn Sie die Workload Identity-Clusterauthentifizierung verwenden, prüft bmctl die Ablaufzeit des Tokens. Wenn das Token innerhalb von 1.800 Sekunden (30 Minuten) abläuft, meldet bmctl einen Fehler und wird beendet.

Anpassung

Sie können Dienstkonten mit eindeutigen Namen für die Workload Identity-Clusterauthentifizierung verwenden, sofern sie Bindungen für die erforderlichen Rollen haben.

1.33 und höher

Standardmäßig wird für die Workload Identity-Clusterauthentifizierung für Cluster ab Version 1.33 nur das Dienstkonto baremetal-gcr verwendet. Daher ist dies das einzige Dienstkonto, das angepasst werden kann.

  1. Prüfen Sie, ob das Dienstkonto, das Sie verwenden möchten, die Rollen hat, die in der Tabelle unter Vorbereitung aufgeführt sind.

  2. Annotieren Sie die Clusterkonfigurationsdatei, um den benutzerdefinierten Namen für das Dienstkonto für die Workload Identity-Clusterauthentifizierung anzugeben:

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: my-cluster
      namespace: cluster-my-cluster
      annotations:
        ...
        baremetal.cluster.gke.io/gcr-service-account: "CUSTOM_AR_GSA"
    spec:
      type: admin
      profile: default
      anthosBareMetalVersion: 1.33.0-gke.799
      ...
    

Ersetzen Sie CUSTOM_AR_GSA durch den E-Mail-Namen des Dienstkontos, das von Google Distributed Cloud zum Herunterladen von Container-Images aus Artifact Registry verwendet wird.

1.30-1.32

  1. Die Dienstkonten, die Sie verwenden möchten, müssen die Rollen haben, die in der Tabelle unter Vorbereitung aufgeführt sind.

  2. Annotieren Sie die Clusterkonfigurationsdatei, um die benutzerdefinierten Namen für die Dienstkonten für die Workload Identity-Clusterauthentifizierung anzugeben:

    Wenn Sie benutzerdefinierte Namen angeben, können Sie vorhandene Dienstkonten verwenden. Achten Sie darauf, dass sich die von Ihnen angegebenen benutzerdefinierten Dienstkontonamen voneinander unterscheiden. Wir unterstützen nicht die Verwendung eines einzelnen Dienstkontos, um zwei oder mehr der Standarddienstkonten zu ersetzen.

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: my-cluster
      namespace: cluster-my-cluster
      annotations:
        ...
        baremetal.cluster.gke.io/controller-service-account: "CUSTOM_CONTROLLER_GSA"
        baremetal.cluster.gke.io/cloud-ops-service-account: "CUSTOM_CLOUD_OPS_GSA"
        baremetal.cluster.gke.io/gcr-service-account: "CUSTOM_AR_GSA"
    spec:
      type: admin
      profile: default
      anthosBareMetalVersion: 1.30.0-gke.1930
      ...
    

Ersetzen Sie Folgendes:

  • CUSTOM_CONTROLLER_GSA: der E-Mail-Name des Dienstkontos, das vom Connect-Agent verwendet wird, um eine Verbindung zwischen Ihrem Cluster und Google Cloudaufrechtzuerhalten und Ihre Cluster zu registrieren.

  • CUSTOM_CLOUD_OPS_GSA: der E-Mail-Name des Dienstkontos, das von Stackdriver Agent verwendet wird, um Logs und Messwerte von Clustern nach Cloud Logging und Cloud Monitoring zu exportieren.

  • CUSTOM_AR_GSA: die E-Mail-Adresse des Dienstkontos, das von Google Distributed Cloud zum Herunterladen von Container-Images aus Artifact Registry verwendet wird.

Beschränkungen

Die folgenden Features und Funktionen werden nicht unterstützt, wenn Sie die Workload Identity-Clusterauthentifizierung für Distributed Cloud-Software nur für Bare Metal verwenden:

  • Proxyserver verwenden
  • VPC Service Controls
  • Vorhandene Cluster im Schlüsselmodus für die Verwendung der Workload Identity-Clusterauthentifizierung aktualisieren
  • Clusterlebenszyklusverwaltung mit GKE On-Prem API-Clients wie der Google Cloud CLI, Terraform oder der Google Cloud Console

Nächste Schritte