In diesem Dokument wird beschrieben, wie Sie die Clusterauthentifizierung mit Workload Identity für Google Distributed Cloud Connected einrichten und verwenden. Anstelle von Dienstkontoschlüsseln werden bei der Clusterauthentifizierung mit Workload Identity kurzlebige Tokens und die Identitätsföderation von Arbeitslasten verwendet, damit Ihre Arbeitslasten sicher auf Google Cloud Ressourcen zugreifen können. Die kurzlebigen Anmeldedaten sind OAuth 2.0-Zugriffstokens. Standardmäßig laufen die Zugriffstokens nach einer Stunde ab.
Mit der Clusterauthentifizierung mit Workload Identity können Ihre Arbeitslasten ihre eigene Kubernetes-Identität verwenden, um direkt auf Ressourcen zuzugreifen Google Cloud oder die Identität eines Google-Dienstkontos zu übernehmen.
Die Clusterauthentifizierung mit Workload Identity bietet zwei Hauptvorteile 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 Identitätsföderation von Arbeitslasten gelten als Best-Practice-Alternativen zu Dienstkontoschlüsseln. Weitere Informationen zu Dienstkontotokens finden Sie unter Kurzlebige Anmeldedaten für das Dienstkonto. Weitere Informationen zur Identitätsföderation von Arbeitslasten finden Sie unter Identitätsföderation von Arbeitslasten.
Weniger Wartung: Dienstkontoschlüssel erfordern mehr Wartung. Das regelmäßige Rotieren und Sichern dieser Schlüssel kann einen erheblichen Verwaltungsaufwand verursachen.
Diese Seite richtet sich an Administratoren, Architekturfachkräfte und Betreiber, die technische Infrastrukturen einrichten, überwachen und verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -aufgaben.
Clusterverwaltung
In diesem Leitfaden wird die Identitätsföderation von Arbeitslasten für Ihre Anwendungen behandelt. Die Identitätsföderation von Arbeitslasten auf Clusterebene wird automatisch für Distributed Cloud Connected-Cluster verwaltet.
Distributed Cloud Connected-Cluster werden von Google über die
Distributed Cloud Edge Container API,
entweder mit dem
gcloud edge-cloud container clusters create
Befehl oder in der Google Cloud Console erstellt und verwaltet.
Distributed Cloud Connected-Cluster werden automatisch in einer Flotte in dem Projekt registriert, in dem sie erstellt wurden. Sie müssen keine manuelle Flottenregistrierung durchführen. Der Pool der Identitätsföderation von Arbeitslasten ist automatisch verfügbar und
hat das Format PROJECT_ID.svc.id.goog.
Hinweis
Bevor Sie die Identitätsföderation von Arbeitslasten einrichten können, prüfen Sie, ob die folgenden APIs in Ihrem Google Cloud Projekt aktiviert sind. Informationen zum Aktivieren von APIs finden Sie unter Dienste aktivieren:
iam.googleapis.comsts.googleapis.comiamcredentials.googleapis.comgkehub.googleapis.com
Prüfen Sie, ob die folgenden Befehlszeilentools installiert sind:
- Die neueste Version der Google Cloud CLI, die
enthält
gcloud, das Befehlszeilentool für die Interaktion mit Google Cloud. kubectl
Wenn Sie Cloud Shell als Shell-Umgebung für die Interaktion mit Google Cloudverwenden, sind diese Tools für Sie installiert.
- Die neueste Version der Google Cloud CLI, die
enthält
Achten Sie darauf, dass die gcloud CLI für die Verwendung mit Ihrem Projekt initialisiert wurde.
Prüfen Sie, ob Sie die folgenden IAM-Rollen für das Projekt haben. Diese Rollen sind für die Einrichtung erforderlich:
- Inhaber (
roles/owner) oder - IAM-Sicherheitsadministrator (
roles/iam.securityAdmin) und Dienstkonto-Administrator (roles/iam.serviceAccountAdmin)
- Inhaber (
In den folgenden Abschnitten erstellen Sie Dienstkonten und gewähren die für die Clusterauthentifizierung mit Workload Identity erforderlichen Rollen.
Empfohlen: Direkter Ressourcen-Zugriff über die Identitätsföderation von Arbeitslasten
Mit dem direkten Ressourcenzugriff über die Workload Identity-Föderation gewähren Sie einem Kubernetes-Dienstkonto mit der Workload Identity-Föderation eine IAM-Rolle, damit es direkt auf Ressourcen zugreifen kann. Google Cloud
| Identität | Zweck | Rollen |
|---|---|---|
| Kubernetes-Dienstkonto |
Die Kubernetes-Identität, die von Ihrer Arbeitslast verwendet wird. Gewähren Sie dieser Identität die
Rollen, die für den Zugriff auf die erforderlichen Google Cloud Ressourcen erforderlich sind. In diesem Beispiel werden die roles/storage.objectViewer Rolle und die roles/logging.admin Rolle gewährt.
|
roles/storage.objectViewerroles/logging.admin |
Alternative: Identitätsübernahme des IAM-Dienstkontos
Alternativ können Sie Ihr Kubernetes-Dienstkonto so konfigurieren, dass es die Identität eines IAM-Dienstkontos übernimmt.
| Dienstkonto | Zweck | Rollen |
|---|---|---|
| Google-Dienstkonto | Das Google-Dienstkonto, dessen Identität von Ihrer In-Cluster-Arbeitslast übernommen wird. Gewähren Sie diesem Dienstkonto die Rollen, die für den Zugriff auf die erforderlichen Google Cloud Ressourcen erforderlich sind. | Hängt von den Ressourcen ab, auf die zugegriffen wird. |
| Kubernetes-Dienstkonto |
Gewähren Sie dieser Identität die Möglichkeit, sich als das Google-Dienstkonto auszugeben.
Für diese Gewährung wird die Rolle roles/iam.workloadIdentityUser verwendet.
|
roles/iam.workloadIdentityUser
|
Dienstkonten einrichten
In den folgenden Abschnitten finden Sie eine Anleitung zum Erstellen des erforderlichen Kubernetes-Dienstkontos und zum Gewähren der erforderlichen Rollen für die Clusterauthentifizierung mit Workload Identity, entweder mit dem direkten Ressourcen-Zugriff über die Workload Identity-Föderation oder mit der Identitätsübernahme des Google-Dienstkontos.
Kubernetes-Dienstkonto erstellen
Erstellen Sie in Ihrem Cluster mit dem
kubectl create
Befehl ein Kubernetes-Dienstkonto für Ihre Pods. Sie können auch ein beliebiges vorhandenes Dienstkonto verwenden, einschließlich des Standarddienstkontos ServiceAccount im Namespace.
kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
Ersetzen Sie die folgenden Werte:
KSA_NAME: ein Name für Ihr Kubernetes-DienstkontoNAMESPACE: der Namespace für Ihren Cluster
Direkten Ressourcen-Zugriff mit der Identitätsföderation von Arbeitslasten gewähren
So gewähren Sie der Identität Ihres Kubernetes-Dienstkontos direkt Identity and Access Management-Rollen:
Verwenden Sie den Befehl gcloud projects describe , um Ihre numerische Projektnummer zu ermitteln:
gcloud projects describe PROJECT_ID --format="value(projectNumber)"Ersetzen Sie
PROJECT_IDdurch die ID Ihres Projekts.Verwenden Sie den Befehl gcloud projects add-iam-policy-binding , um dem Kubernetes-Identitätshauptkonto die erforderlichen Rollen zu gewähren:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member="principal://iam.gserviceaccount.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role=roles/storage.objectViewer gcloud projects add-iam-policy-binding PROJECT_ID \ --member="principal://iam.gserviceaccount.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role=roles/logging.adminErsetzen Sie die folgenden Werte:
PROJECT_NUMBER: Ihre numerische ProjektnummerNAMESPACE: der Namespace für Ihren ClusterKSA_NAME: der Name für Ihr Kubernetes-Dienstkonto
Alternative: Zugriff mit Identitätsübernahme des IAM-Dienstkontos gewähren
Wenn Sie möchten, dass Ihre Arbeitslasten die Identität eines Google-Dienstkontos übernehmen, führen Sie die folgenden Schritte aus.
Verwenden Sie den Befehl gcloud iam service-accounts create , um ein Google-Dienstkonto zu erstellen:
gcloud iam service-accounts create my-app-sa \ --project=PROJECT_IDErsetzen Sie
PROJECT_IDdurch die ID Ihres Projekts.Verwenden Sie den Befehl gcloud projects add-iam-policy-binding , um dem Google-Dienstkonto die erforderlichen Rollen zu gewähren:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:my-app-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/storage.objectViewer gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:my-app-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/logging.adminVerwenden Sie den gcloud iam service-accounts add-iam-policy-binding Befehl, um dem Kubernetes-Dienstkonto die Möglichkeit zu gewähren, die Identität des Google Dienstkontos zu übernehmen:
gcloud iam service-accounts add-iam-policy-binding my-app-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"Ersetzen Sie die folgenden Werte:
NAMESPACE: der Namespace für Ihren ClusterKSA_NAME: der Name für Ihr Kubernetes-Dienstkonto
Verwenden Sie den kubectl annotate Befehl, um das Kubernetes-Dienstkonto zu annotieren und mit dem Google Dienstkonto zu verknüpfen:
kubectl annotate serviceaccount \ --namespace NAMESPACE KSA_NAME \ iam.gke.io/gcp-service-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com
Arbeitslast konfigurieren
Aktualisieren Sie die Pod-Spezifikation, um das Kubernetes-Dienstkonto zu verwenden und das projizierte Token-Volume einzubinden. Da sich Distributed Cloud Connected-Cluster außerhalb von
Google Cloudbefinden, müssen Sie auch eine Konfigurationsdatei für Anmeldedaten angeben und die
GOOGLE_APPLICATION_CREDENTIALS Umgebungsvariable so festlegen, dass sie auf diese Datei verweist.
Google Cloud Clientbibliotheken im Pod verwenden diese, um das
Kubernetes-Token über die Security Token Service API gegen ein Google Cloud Zugriffstoken auszutauschen.
Generieren Sie die Datei
credential-configuration.json. Wählen Sie den Befehl je nachdem aus, ob Sie den direkten Ressourcen-Zugriff über die Identitätsföderation von Arbeitslasten oder die Identitätsübernahme des IAM-Dienstkontos verwenden.Direkter Ressourcen-Zugriff über die Identitätsföderation von Arbeitslasten
Verwenden Sie den Befehl gcloud iam workload-identity-pools create-cred-config:
gcloud iam workload-identity-pools create-cred-config \ projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/providers/attestor \ --credential-source-file=/var/run/secrets/tokens/gcp-ksa/token \ --credential-source-type=text \ --output-file=credential-configuration.jsonZugriff mit Identitätsübernahme des IAM-Dienstkontos gewähren
Verwenden Sie den Befehl gcloud iam workload-identity-pools create-cred-config:
gcloud iam workload-identity-pools create-cred-config \ projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/providers/attestor \ --service-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com \ --credential-source-file=/var/run/secrets/tokens/gcp-ksa/token \ --credential-source-type=text \ --output-file=credential-configuration.jsonErsetzen Sie
PROJECT_NUMBERdurch Ihre Google Cloud Projekt nummer. Sie finden die Projektnummer, indem Siegcloud projects describe PROJECT_ID --format="value(projectNumber)"ausführen.Verwenden Sie den
kubectl create configmapBefehl, um eine Kubernetes-ConfigMapzum Speichern der Konfigurationsdatei zu erstellen:kubectl create configmap CREDENTIAL_CONFIG_MAP \ --namespace NAMESPACE \ --from-file=credential-configuration.jsonErsetzen Sie die folgenden Werte:
CREDENTIAL_CONFIG_MAP: ein Name für IhreConfigMap, die Ihre Konfigurationsdatei für Anmeldedaten enthältNAMESPACE: der Namespace für Ihren Cluster
Aktualisieren Sie Ihre Pod-Spezifikation mit dem folgenden YAML-Inhalt:
spec: serviceAccountName: KSA_NAME containers: - name: MY_CONTAINER image: MY_IMAGE env: - name: GOOGLE_APPLICATION_CREDENTIALS value: /var/run/secrets/tokens/gcp-creds/credential-configuration.json volumeMounts: - mountPath: /var/run/secrets/tokens/gcp-ksa name: gcp-ksa - mountPath: /var/run/secrets/tokens/gcp-creds name: gcp-creds readOnly: true volumes: - name: gcp-ksa projected: defaultMode: 0420 sources: - serviceAccountToken: path: token audience: PROJECT_ID.svc.id.goog expirationSeconds: 3600 - name: gcp-creds configMap: name: CREDENTIAL_CONFIG_MAPErsetzen Sie die folgenden Werte:
KSA_NAME: ein Name für Ihr Kubernetes-DienstkontoMY_CONTAINER: der Name Ihres ContainersMY_IMAGE: der Name Ihres Images
Beschränkungen
Die folgenden Features und Funktionen werden nicht unterstützt, wenn Sie die Identitätsföderation von Arbeitslasten für Distributed Cloud Connected verwenden:
- Proxyserver für den Tokenaustauschprozess verwenden
Informationen zur Verwendung der Identitätsföderation von Arbeitslasten mit VPC Service Controls, siehe VPC Service Controls-Integration konfigurieren.
Nächste Schritte
- Arbeitslasten in Distributed Cloud Connected bereitstellen
- Dienste verwalten
- Best Practices für die Sicherheit anwenden