In diesem Dokument wird beschrieben, wie Sie die Clusterauthentifizierung für Workload Identity für Google Distributed Cloud Connected einrichten und verwenden. Anstelle von Dienstkontoschlüsseln werden bei der Workload Identity-Clusterauthentifizierung 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 über Workload Identity können Ihre Arbeitslasten ihre eigene Kubernetes-Identität verwenden, um direkt auf Google Cloud -Ressourcen zuzugreifen oder die Identität eines Google-Dienstkontos zu übernehmen.
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 das Dienstkonto. Weitere Informationen zur Workload Identity-Föderation finden Sie unter Workload Identity-Föderation.
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 inGoogle 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 Workload Identity-Föderation auf Clusterebene wird für verbundene Distributed Cloud-Cluster automatisch verwaltet.
Verbundene Distributed Cloud-Cluster werden von Google über die Distributed Cloud Edge Container API erstellt und verwaltet, entweder über den gcloud edge-cloud container clusters create-Befehl oder in der Google Cloud -Konsole.
Distributed Cloud-Cluster werden automatisch in einer Flotte in dem Projekt registriert, in dem sie erstellt werden. Sie müssen keine manuelle Flottenregistrierung vornehmen. Der Workload Identity-Föderationspool ist automatisch verfügbar und hat das Format PROJECT_ID.svc.id.goog.
Hinweis
Bevor Sie die Workload Identity-Föderation einrichten können, müssen Sie prüfen, 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
gcloud, das Befehlszeilentool für die Interaktion mit Google Cloud, enthält. kubectl
Wenn Sie Cloud Shell als Shell-Umgebung für die Interaktion mitGoogle Cloudverwenden, sind diese Tools für Sie installiert.
- Die neueste Version der Google Cloud CLI, die
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 Dienstkontoadministrator (roles/iam.serviceAccountAdmin)
- Inhaber (
In den folgenden Abschnitten erstellen Sie Dienstkonten und weisen Rollen zu, die für die Clusterauthentifizierung mit Workload Identity erforderlich sind.
Empfohlen: Direkter Ressourcenzugriff über die Workload Identity-Föderation
Beim direkten Ressourcenzugriff über die Workload Identity-Föderation weisen Sie einem Kubernetes-Dienstkonto mithilfe der Workload Identity-Föderation eine IAM-Rolle zu, damit es direkt auf Google Cloud-Ressourcen zugreifen kann.
| Identität | Zweck | Rollen |
|---|---|---|
| Kubernetes-Dienstkonto |
Die Kubernetes-Identität, die von Ihrer Arbeitslast verwendet wird. Weisen Sie dieser Identität die Rollen zu, die für den Zugriff auf die erforderlichen Google Cloud Ressourcen erforderlich sind. In diesem Beispiel werden die Rollen roles/storage.objectViewer und roles/logging.admin zugewiesen.
|
roles/storage.objectViewerroles/logging.admin |
Alternative: Identitätsübernahme des IAM-Dienstkontos
Alternativ können Sie Ihr Kubernetes-Dienstkonto für die Identitätsübernahme des IAM-Dienstkontos konfigurieren.
| Dienstkonto | Zweck | Rollen |
|---|---|---|
| Google-Dienstkonto | Das Google-Dienstkonto, dessen Identität von Ihrer In-Cluster-Arbeitslast übernommen wird. Weisen Sie diesem Dienstkonto die Rollen zu, die für den Zugriff auf die erforderlichen Google Cloud Ressourcen benötigt werden. | Hängt von den Ressourcen ab, auf die zugegriffen wird. |
| Kubernetes-Dienstkonto |
Gewähren Sie dieser Identität die Berechtigung, die Identität des Google-Dienstkontos zu übernehmen.
Für diese Zuweisung wird die Rolle roles/iam.workloadIdentityUser verwendet.
|
roles/iam.workloadIdentityUser
|
Dienstkonten einrichten
Die folgenden Abschnitte enthalten Anleitungen zum Erstellen des erforderlichen Kubernetes-Dienstkontos und zum Zuweisen der erforderlichen Rollen für die Clusterauthentifizierung mit Workload Identity mithilfe von Workload Identity Federation für den direkten Ressourcenzugriff oder der Identitätsübernahme von Google-Dienstkonten.
Kubernetes-Dienstkonto erstellen
Verwenden Sie in Ihrem Cluster den Befehl kubectl create, um ein Kubernetes-ServiceAccount für Ihre Pods zu erstellen. Sie können auch ein beliebiges vorhandenes Dienstkonto verwenden, einschließlich des Standard-ServiceAccount im Namespace.
kubectl create serviceaccount KUBERNETES_SERVICEACCOUNT --namespace NAMESPACE
Ersetzen Sie die folgenden Werte:
KUBERNETES_SERVICEACCOUNT: Ein Name für Ihr Kubernetes-ServiceAccountNAMESPACE: der Namespace für Ihren Cluster
Workload Identity-Föderation verwenden, um direkten Ressourcenzugriff zu gewähren
So weisen Sie Ihrer Kubernetes-Dienstkontoidentität direkt IAM-Rollen (Identity and Access Management) zu:
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 zuzuweisen:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KUBERNETES_SERVICEACCOUNT" \ --role=roles/storage.objectViewer gcloud projects add-iam-policy-binding PROJECT_ID \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KUBERNETES_SERVICEACCOUNT" \ --role=roles/logging.adminErsetzen Sie die folgenden Werte:
PROJECT_NUMBER: Ihre numerische ProjektnummerNAMESPACE: der Namespace für Ihren ClusterKUBERNETES_SERVICEACCOUNT: Der Name für Ihr Kubernetes-ServiceAccount.
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, folgen Sie dieser Anleitung.
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 zuzuweisen:
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 Befehl gcloud iam service-accounts add-iam-policy-binding, um dem Kubernetes-Dienstkonto die Möglichkeit zu geben, 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/KUBERNETES_SERVICEACCOUNT]"Ersetzen Sie die folgenden Werte:
NAMESPACE: der Namespace für Ihren ClusterKUBERNETES_SERVICEACCOUNT: Der Name für Ihr Kubernetes-ServiceAccount.
Verwenden Sie den Befehl kubectl annotate, um das Kubernetes-Dienstkonto zu annotieren und mit dem Google-Dienstkonto zu verknüpfen:
kubectl annotate serviceaccount \ --namespace NAMESPACE KUBERNETES_SERVICEACCOUNT \ 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 bereitzustellen. Da verbundene Distributed Cloud-Cluster außerhalb vonGoogle Cloudliegen, müssen Sie auch eine Konfigurationsdatei für Anmeldedaten bereitstellen und die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS 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 einzutauschen.
Erstellen Sie die Datei
credential-configuration.json. Wählen Sie den Befehl je nachdem aus, ob Sie den direkten Ressourcenzugriff über die Identitätsföderation von Arbeitslasten oder die Identitätsübernahme des IAM-Dienstkontos verwenden.Direkter Ressourcenzugriff ü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 die Google Cloud Projektnummer. Sie können die Projektnummer ermitteln. Führen Sie dazu Folgendes aus:gcloud projects describe PROJECT_ID --format="value(projectNumber)"Verwenden Sie den Befehl
kubectl create configmap, um ein 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 IhrConfigMap, das 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: KUBERNETES_SERVICEACCOUNT 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:
KUBERNETES_SERVICEACCOUNT: Ein Name für Ihr Kubernetes-ServiceAccount.MY_CONTAINER: der Name Ihres ContainersMY_IMAGE: der Name Ihres Bildes
Beschränkungen
Die folgenden Funktionen und Features werden nicht unterstützt, wenn Sie die Workload Identity Federation für Distributed Cloud Connected verwenden:
- Proxyserver für den Tokenaustausch verwenden
Informationen zur Verwendung von Workload Identity Federation mit VPC Service Controls finden Sie unter VPC Service Controls-Integration konfigurieren.
Nächste Schritte
- Arbeitslasten in Distributed Cloud Connected bereitstellen
- Dienste verwalten
- Best Practices für die Sicherheit anwenden