In diesem Leitfaden wird beschrieben, wie Sie mit Workload Identity-Föderation Bereitstellungspipelines bei Google Cloud authentifizieren.
Je nach verwendetem CI/CD-System haben Ihre Bereitstellungspipelines möglicherweise Zugriff auf umgebungsspezifische Anmeldedaten. Beispiele:
- Azure DevOps-Pipelines können eine Microsoft Entra Workload Identity-Föderationsdienstverbindung verwenden, um ein ID-Token abzurufen, das das Azure DevOps-Projekt eindeutig identifiziert.
- GitHub Actions-Workflows können ein GitHub-OIDC-Token abrufen, das den Workflow und sein Repository eindeutig identifiziert.
- Mit GitLab SaaS können CI/CD-Jobs auf ein ID-Token zugreifen, das den Job und sein Projekt, seine Umgebung und sein Repository eindeutig identifiziert.
- Terraform Cloud kann Ihrer Terraform-Konfiguration ein OIDC-Token bereitstellen, das den Arbeitsbereich und die Umgebung eindeutig identifiziert.
Sie können Ihre Bereitstellungspipelines so konfigurieren, dass sie diese Anmeldedaten mithilfe der Workload Identity-Föderation zur Authentifizierung bei Google Cloud verwenden. Bei diesem Ansatz entfallen die mit Dienstkontoschlüsseln verbundenen Wartungs- und Sicherheitsaufwand.
Hinweise
Authentifizierung einrichten
Wählen Sie den Tab für die Verwendung der Beispiele auf dieser Seite aus:
Console
Wenn Sie über die Google Cloud Console auf Google Cloud-Dienste und -APIs zugreifen, müssen Sie die Authentifizierung nicht einrichten.
gcloud
Sie können die gcloud CLI-Beispiele auf dieser Seite über eine der folgenden Entwicklungsumgebungen verwenden:
-
Cloud Shell: Aktivieren Sie Cloud Shell, um ein Onlineterminal mit der bereits eingerichteten gcloud CLI zu verwenden.
Unten auf dieser Seite wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Das Initialisieren der Sitzung kann einige Sekunden dauern.
-
Lokale Shell: Zur Verwendung der gcloud CLI in einer lokalen Entwicklungsumgebung müssen Sie die gcloud CLI installieren und initialisieren.
Python
Wenn Sie die Python-Beispiele auf dieser Seite aus einer lokalen Entwicklungsumgebung heraus verwenden möchten, installieren und initialisieren Sie die gcloud CLI und richten dann die Standardanmeldedaten für Anwendungen mit Ihren Nutzeranmeldedaten ein.
- Installieren Sie die Google Cloud CLI.
-
Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:
gcloud init
-
Erstellen Sie lokale Anmeldedaten zur Authentifizierung für Ihr Google-Konto:
gcloud auth application-default login
Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten in der Dokumentation zur Google Cloud-Authentifizierung.
Erforderliche Rollen
Bitten Sie Ihren Administrator, Ihnen die .Workload Identity-Pooladministrator roles/iam.workloadIdentityPoolAdmin
IAM-Rolle für das Projekt zu erteilen, um Berechtigung zu bekommen, die Sie zum Konfigurieren der Workload Identity-Föderation benötigen.
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.
Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.
Alternativ enthält die einfache Rolle „IAM-Inhaber“ (roles/owner
) auch Berechtigungen zum Konfigurieren der Identitätsföderation.
In einer Produktionsumgebung sollten Sie keine einfachen Rollen zuweisen, Sie können sie aber in einer Entwicklungs- oder Testumgebung gewähren.
Externen IdP vorbereiten
Azure DevOps
Damit sich eine Azure DevOps-Pipeline bei Google Cloud authentifizieren kann, müssen Sie zuerst eine Dienstverbindung für Azure Resource Manager konfigurieren. Über diese Verbindung kann die Pipeline ein ID-Token abrufen, das dann gegen Google Cloud-Anmeldedaten ausgetauscht werden kann.
So erstellen Sie eine Dienstverbindung für Azure Resource Manager:
- Öffnen Sie in Azure DevOps Ihr Projekt und rufen Sie Project Settings (Projekteinstellungen) auf.
- Rufen Sie Pipelines > Dienstverbindungen auf.
- Klicken Sie auf Dienstverbindung erstellen.
- Wählen Sie Azure Resource Manager aus.
- Klicken Sie auf Next (Weiter).
- Wählen Sie Workload Identity-Föderation (automatisch) aus.
- Klicken Sie auf Next (Weiter).
Legen Sie folgende Einstellungen fest:
Umfangsebene: Wählen Sie ein Abo aus.
Sie müssen ein Abo auswählen, auch wenn Sie nicht die Dienstverbindung für den Zugriff auf Azure-Ressourcen verwenden möchten.
Name der Dienstverbindung: Geben Sie einen Namen wie
google-cloud
ein.
Klicken Sie auf Speichern.
In einem späteren Schritt benötigen Sie die Aussteller- und Subjekt-ID der Dienstverbindung. So finden Sie diese Details:
- Klicken Sie auf die Dienstverbindung, die Sie gerade erstellt haben.
- Klicken Sie auf Diensthauptkonto verwalten.
- Rufen Sie Zertifikat & Secrets > Föderierte Anmeldedaten auf.
- Klicken Sie auf die föderierten Anmeldedaten.
Suchen Sie auf der Seite Anmeldedaten bearbeiten die folgenden Kennzeichnungen:
- Aussteller: identifiziert Ihre Azure DevOps-Organisation eindeutig
- Themenkennung: identifiziert die Dienstverbindung eindeutig
Azure DevOps gewährt automatisch dem Diensthauptkonto, das der neuen Dienstverbindung zugeordnet ist, Zugriff auf das Abo, das Sie als Bereich ausgewählt haben. Da Sie nicht die Dienstverbindung für den Zugriff auf Azure-Ressourcen verwenden möchten, können Sie diesen Zugriff so widerrufen:
- Öffnen Sie im Azure-Portal das Abo, das Sie als Bereich ausgewählt haben.
- Gehen Sie zu Zugriffssteuerung (IAM) > Rollenzuweisungen.
- Suchen Sie die Rollenzuweisung für die Dienstverbindung und entfernen Sie sie.
GitHub Actions
Sie müssen keine Änderungen an der Konfiguration in Ihrem GitHub-Konto vornehmen.
Nachdem Sie einen Workload Identity-Pool so konfiguriert haben, dass er Ihrem GitHub-Repository vertraut, können Sie zulassen, dass Workflows in diesem Repository ihr GitHub-OIDC-Token verwenden, um kurzlebige Google Cloud-Anmeldedaten abzurufen.
GitLab SaaS
Sie müssen keine Änderungen an der Konfiguration in Ihrem GitLab-Konto vornehmen.
Nachdem Sie einen Workload Identity-Pool für die Vertrauensstellung Ihrer GitLab-Gruppe konfiguriert haben, können Sie die Workload Identity-Föderation für einzelne CI/CD-Jobs aktivieren.
Terraform Cloud
Sie müssen keine Änderungen an der Konfiguration in Ihrem Terraform Cloud-Konto vornehmen.
Nachdem Sie einen Workload Identity-Pool für die Vertrauensstellung von Terraform Cloud konfiguriert haben, können Sie die Identitätsföderation von Arbeitslasten für einzelne Arbeitsbereiche aktivieren.
Workload Identity-Föderation konfigurieren
Sie müssen diese Schritte für jede GitHub-Organisation, GitLab-Gruppe oder Terraform Cloud-Organisation ausführen.
So konfigurieren Sie die Workload Identity-Föderation:
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
Es wird empfohlen, ein dediziertes Projekt zum Verwalten von Workload Identity-Pools und -Anbietern zu verwenden.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs aktivieren.
Attributzuordnung definieren
Die umgebungsspezifischen Anmeldedaten Ihrer Bereitstellungspipeline enthalten mehrere Attribute. Sie müssen entscheiden, welches Attribut Sie in Google Cloud als Subjekt-ID (google.subject
) verwenden möchten.
Optional können Sie zusätzliche Attribute zuordnen. Sie können dann auf diese zusätzlichen Attribute verweisen, wenn Sie Zugriff auf Ressourcen gewähren.
Azure DevOps
Das Azure DevOps-ID-Token enthält eine sub
-Anforderung, die die Subjekt-ID Ihrer Dienstverbindung enthält. Die Betreff-ID hat folgendes Format:
sc://ORGANIZATION/PROJECT/CONNECTION
Verwenden Sie die folgende Attributzuordnung, um diesen Bezeichner google.subject
zuzuordnen:
google.subject=assertion.sub
GitHub Actions
Ihre Attributzuordnungen können beliebige Anforderungen im OIDC-Token von GitHub Actions verwenden. Diese Token-Anforderungsschlüssel und ihre Werte werden von GitHub gesteuert. Sie sollten mindestens google.subject
zu assertion.sub
zuordnen, was dem OIDC-Token-Subjekt von GitHub Actions entspricht:
google.subject=assertion.sub
Der Wert des GitHub Actions-OIDC-Tokens-Subjekts kann je nach Quellereignis variieren. Weitere Anspruchsattribute können sein:
repository
: Enthält den Namen des Inhabers und des Repositorys, z. B."google/guava"
.repository_id
: Enthält die eindeutige Repository-ID, z. B."20300177"
.repository_owner
: Enthält den Inhaber, der ein Nutzername oder der Name einer GitHub-Organisation sein kann, z. B."google"
.repository_owner_id
: Enthält die eindeutige Inhaber-ID, z. B."1342004"
.
Die Liste oben ist eine Teilmenge der möglichen Anforderungen. Eine vollständige Liste finden Sie in der GitHub-Dokumentation unter Beispielanforderungen. Achten Sie darauf, alle Anforderungen zuzuordnen, die Sie als Attributbedingungen oder als Teil einer zukünftigen principalSet
-Bedingung verwenden möchten.
GitLab SaaS
Ihre Attributzuordnungen können die im GitLab-ID-Token eingebetteten Anforderungen als Quellattribute verwenden, darunter:
sub
: der Projektname und die Git-Referenz, z. B.project_path:groupname/projectname:ref_type:branch:ref:main
namespace_id
: die eindeutige Gruppen-ID.project_id
: die eindeutige Projekt-ID.user_id
: die eindeutige Nutzer-ID.environment
: Die Umgebung, für die der Job gilt.ref_path
: die Git-Referenz, z. B.refs/heads/main
Mit der folgenden Attributzuordnung wird google.subject
auf die Anforderung sub
aus dem GitLab-ID-Token festgelegt. Da die Anforderung sub
sowohl den Projektnamen als auch die Git-Referenz enthält, können Sie über diese Zuordnung den Zugriff nach Repository und Zweig steuern:
google.subject=assertion.sub
Die Steuerung des Zugriffs nach Repository und Zweig kann nützlich sein, wenn bestimmte Zweige (z. B. main
) anderen Zugriff auf Ressourcen benötigen als andere Zweige (z. B. Feature-Zweige).
In einigen Fällen kann es ausreichend sein, den Zugriff nur nach Projekt oder Gruppe zu unterscheiden. Die folgende Zuordnung enthält daher zwei zusätzliche Attribute mit der project_id
und der namespace_id
von GitLab:
google.subject=assertion.sub attribute.project_id=assertion.project_id attribute.namespace_id=assertion.namespace_id
Terraform Cloud
Ihre Attributzuordnungen können die im OIDC-Token von Terraform Cloud eingebetteten Anforderungen verwenden, darunter:
terraform_organization_id
: Enthält die eindeutige ID der Organisation, z. B.org-xxxxxxxxxxxxxxxx
.terraform_workspace_id
: Enthält die eindeutige ID des Arbeitsbereichs, z. B.ws-xxxxxxxxxxxxxxxx
.terraform_workspace_name
: Enthält den Anzeigenamen des Arbeitsbereichs.sub
: Enthält den Anzeigenamen der Organisation, des Arbeitsbereichs und der Phase, z. B.organization:example-org:workspace:example-workspace:run_phase:apply
.
Mit der folgenden Attributzuordnung wird google.subject
auf die Anforderung terraform_workspace_id
aus dem OIDC-Token von Terraform Cloud festgelegt:
google.subject=assertion.terraform_workspace_id
Mit dieser Zuordnung können Sie den Zugriff auf Google Cloud-Ressourcen nach Arbeitsbereich steuern.
Attributbedingung definieren
Attributbedingungen sind CEL-Ausdrücke, die Assertion-Attribute und Zielattribute prüfen können. Wenn die Attributbedingung bei bestimmten Anmeldedaten als true
ausgewertet wird, werden die Anmeldedaten akzeptiert. Andernfalls werden die Anmeldedaten abgelehnt. Für alle Attributbedingungsfelder benötigen Sie eine Attributzuordnung.
Azure DevOps
Verwenden Sie optional eine Attributbedingung, um den Zugriff auf bestimmte Dienstverbindungen einzuschränken. Die folgende Bedingung beschränkt beispielsweise den Zugriff auf Verbindungen in einem bestimmten Azure DevOps-Projekt:
assertion.sub.startsWith('sc://ORGANIZATION/PROJECT/')
Ersetzen Sie Folgendes:
ORGANIZATION
: der Name Ihrer Azure DevOps-OrganisationPROJECT
: der Name Ihres Azure DevOps-Projekts.
GitHub Actions
Verwenden Sie die folgende Attributbedingung, um den Zugriff auf Tokens einzuschränken, die von Ihrer GitHub-Organisation ausgegeben werden:
assertion.repository_owner=='ORGANIZATION'
Ersetzen Sie dabei ORGANIZATION
durch den Namen Ihrer GitHub-Organisation.
Optional können Sie die Attributbedingung erweitern, um den Zugriff auf eine Teilmenge von Workflows oder Zweigen zu beschränken. Die folgende Bedingung begrenzt beispielsweise den Zugriff auf Workflows, die den Git-Zweig main
verwenden:
assertion.repository_owner=='ORGANIZATION' && assertion.ref=='refs/heads/main'
GitLab SaaS
Verwenden Sie die folgende Attributbedingung, um den Zugriff auf Tokens einzuschränken, die von Ihrer GitLab-Gruppe ausgestellt werden.
assertion.namespace_id=='GROUP_ID'
Ersetzen Sie GROUP_ID
durch die Gruppen-ID, die auf der Startseite Ihrer GitLab-Gruppe angezeigt wird.
Erweitern Sie optional die Attributbedingung, um den Zugriff auf eine Teilmenge von Projekten, Zweige oder Umgebungen einzuschränken. Die folgende Bedingung begrenzt beispielsweise den Zugriff auf Jobs, die die Umgebung production
verwenden:
assertion.namespace_id=='GROUP_ID' && assertion.environment=='production'
Terraform Cloud
Verwenden Sie die folgende Attributbedingung, um den Zugriff auf Tokens einzuschränken, die von Ihrer Terraform Cloud-Organisation ausgestellt werden:
assertion.terraform_organization_id=='ORGANIZATION_ID'
Ersetzen Sie ORGANIZATION_ID
durch die eindeutige ID Ihrer Organisation, z. B. org-xxxxxxxxxxxxxxxx
.
Optional können Sie die Attributbedingung erweitern, um den Zugriff auf eine Teilmenge von Workflows oder Zweigen zu beschränken. Die folgende Attributbedingung beschränkt beispielsweise den Zugriff auf einen bestimmten Arbeitsbereich:
assertion.terraform_organization_id=='ORGANIZATION_ID' && terraform_workspace_id=='WORKSPACE_ID'
Workload Identity-Pool und -Anbieter erstellen
Sie haben jetzt alle Informationen erfasst, die Sie zum Erstellen eines Workload Identity-Pools und -Anbieters benötigen:
Console
Rufen Sie in der Google Cloud Console die Seite Neuer Arbeitslastanbieter und -Pool auf.
Geben Sie unter Identity-Pool erstellen Folgendes ein:
- Name: ist der Name für den Pool. Der Name wird auch als Pool-ID verwendet. Sie können die Pool-ID später nicht ändern.
- Beschreibung: Text, der den Zweck des Pools beschreibt.
Klicken Sie auf Weiter.
Anbietereinstellungen konfigurieren:
Azure DevOps
- Anbieter auswählen: OpenID Connect (OIDC).
- Anbietername: der Name des Azure DevOps-Projekts oder ein benutzerdefinierter Name.
- Anbieter-ID: der Name des Azure DevOps-Projekts oder eine benutzerdefinierte ID. Sie können die Anbieter-ID später nicht mehr ändern.
- Aussteller-URL: der Aussteller der Dienstverbindung, den Sie zuvor nachgeschlagen haben.
Zielgruppen: Wählen Sie Zulässige Zielgruppen aus und fügen Sie den folgenden Wert ein:
api://AzureADTokenExchange
GitHub Actions
- Anbieter auswählen: OpenID Connect (OIDC).
- Name des Anbieters: Name des Anbieters.
- Anbieter-ID: ID des Anbieters. Sie können die Anbieter-ID später nicht mehr ändern.
- Aussteller-URL:
https://token.actions.githubusercontent.com/
- Zielgruppen: Standardzielgruppe
GitLab SaaS
- Anbieter auswählen: OpenID Connect (OIDC).
- Name des Anbieters: Name des Anbieters.
- Anbieter-ID: ID des Anbieters. Sie können die Anbieter-ID später nicht mehr ändern.
- Aussteller-URL:
https://gitlab.com
- Zielgruppen: Standardzielgruppe
Terraform Cloud
- Anbieter auswählen: OpenID Connect (OIDC).
- Name des Anbieters: Name des Anbieters.
- Anbieter-ID: ID des Anbieters. Sie können die Anbieter-ID später nicht mehr ändern.
- Aussteller-URL:
https://app.terraform.io
- Zielgruppen: Standardzielgruppe
Klicken Sie auf Weiter.
Fügen Sie unter Anbieterattribute konfigurieren die zuvor identifizierten Attributzuordnungen hinzu.
Geben Sie unter Attributbedingungen die zuvor identifizierte Attributbedingung ein.
Klicken Sie auf Speichern, um den Workload Identity-Pool und -Poolanbieter zu erstellen.
gcloud
Erstellen Sie einen neuen Workload Identity-Pool:
gcloud iam workload-identity-pools create POOL_ID \ --location="global" \ --description="DESCRIPTION" \ --display-name="DISPLAY_NAME"
Ersetzen Sie die folgenden Werte:
POOL_ID
: die eindeutige ID des PoolsDISPLAY_NAME
: der Name des PoolsDESCRIPTION
: die Beschreibung des Pools. Diese Beschreibung wird angezeigt, wenn Zugriff auf Poolidentitäten gewährt wird.
Fügen Sie einen Workload Identity-Poolanbieter hinzu:
Azure DevOps
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \ --location="global" \ --workload-identity-pool="POOL_ID" \ --issuer-uri="ISSUER" \ --attribute-mapping="MAPPINGS" \ --attribute-condition="CONDITIONS"
Ersetzen Sie die folgenden Werte:
PROVIDER_ID
: der Name des Azure DevOps-Projekts oder eine benutzerdefinierte ID für den Anbieter.POOL_ID
: die ID des Pools.ISSUER
: der Aussteller der Dienstverbindung, den Sie zuvor nachgeschlagen haben.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert habenCONDITIONS
: die zuvor identifizierte Attributbedingung
GitHub Actions
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \ --location="global" \ --workload-identity-pool="POOL_ID" \ --issuer-uri="https://token.actions.githubusercontent.com/" \ --allowed-audiences="api://AzureADTokenExchange" \ --attribute-mapping="MAPPINGS" \ --attribute-condition="CONDITIONS"
Ersetzen Sie die folgenden Werte:
PROVIDER_ID
: die eindeutige ID des AnbietersPOOL_ID
: die ID des Pools.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert habenCONDITIONS
: die zuvor identifizierte Attributbedingung
GitLab SaaS
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \ --location="global" \ --workload-identity-pool="POOL_ID" \ --issuer-uri="https://gitlab.com" \ --attribute-mapping="MAPPINGS" \ --attribute-condition="CONDITIONS"
Ersetzen Sie die folgenden Werte:
PROVIDER_ID
: die eindeutige ID des AnbietersPOOL_ID
: die ID des Pools.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert habenCONDITIONS
: die zuvor identifizierte Attributbedingung
Terraform Cloud
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \ --location="global" \ --workload-identity-pool="POOL_ID" \ --issuer-uri="https://app.terraform.io" \ --attribute-mapping="MAPPINGS" \ --attribute-condition="CONDITIONS"
Ersetzen Sie die folgenden Werte:
PROVIDER_ID
: die eindeutige ID des Anbieters.POOL_ID
: die ID des Pools.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben.CONDITIONS
: zuvor identifizierte Attributbedingung.
Attributbedingung für einen Workload Identity-Anbieter aktualisieren
In diesem Abschnitt wird beschrieben, wie Sie die Attributbedingung für einen vorhandenen Workload Identity-Poolanbieter aktualisieren, um den Zugriff auf von Ihrer GitHub-Organisation, GitLab-Gruppe oder Terraform Cloud-Organisation ausgegeben Tokens einzuschränken.
Informationen zur empfohlenen Attributbedingung für Ihre Pipeline finden Sie unter Attributbedingung definieren.
Console
Rufen Sie in der Google Cloud Console die Seite Workload Identity-Pools auf.
Suchen Sie nach dem Workload Identity-Pool, der den Anbieter enthält, und klicken Sie dann auf das Symbol
Knoten für den Pool maximieren.Suchen Sie den Workload Identity-Poolanbieter, den Sie bearbeiten möchten, und klicken Sie auf
Bearbeiten.Geben Sie unter Attributbedingungen die zuvor identifizierte Attributbedingung ein.
Klicken Sie zum Aktualisieren des Workload Identity-Pools und -Anbieters auf Speichern.
gcloud
Führen Sie folgenden Befehl aus, um den Anbieter des Workload Identity-Pools zu aktualisieren:
gcloud iam workload-identity-pools providers update-oidc PROVIDER_ID \ --location="global" \ --workload-identity-pool="POOL_ID" \ --attribute-condition="CONDITIONS"
Ersetzen Sie die folgenden Werte:
PROVIDER_ID
: die eindeutige ID des AnbietersPOOL_ID
: die ID des Pools.CONDITIONS
: zuvor identifizierte Attributbedingung.
Bereitstellungspipeline authentifizieren
Sie müssen diese Schritte für jeden GitHub Actions-Workflow oder jeden Terraform Cloud-Arbeitsbereich ausführen.
Dienstkonto für die Bereitstellungspipeline erstellen
IAM, Security Token Service, and Service Account Credentials APIs aktivieren.
Erstellen Sie ein Dienstkonto, das die Arbeitslast darstellt. Wir empfehlen, für jede Bereitstellungspipeline ein eigenes Dienstkonto zu verwenden.
Das Dienstkonto muss sich nicht im selben Projekt wie der Workload Identity-Pool befinden.
Gewähren Sie dem Dienstkonto Zugriff auf Ressourcen, auf die externe Identitäten zugreifen können sollen.
Der Bereitstellungspipeline erlauben, die Identität des Dienstkontos zu übernehmen
Damit externe Identitäten die Identität eines Dienstkontos übernehmen können, müssen Sie ihnen die Rolle "Workload Identity-Nutzer" (roles/iam.workloadIdentityUser
) für das Dienstkonto zuweisen. Sie können die Rolle einer bestimmten externen Identität oder mehreren externen Identitäten zuweisen:
- Schreiben Sie für eine bestimmte externe Identität eine Attributbedingung, die das Attribut
google.subject
prüft. - Schreiben Sie für eine Gruppe externer Identitäten eine Attributbedingung, die das Attribut
google.groups
oder ein benutzerdefiniertes Attributattribute.NAME
prüft.
Console
So nutzen Sie die Google Cloud Console, um zuzulassen, dass externe Identitäten die Identität eines Dienstkontos übernehmen:
Rufen Sie in der Google Cloud Console die Seite Workload Identity-Pools auf.
Suchen Sie den Workload Identity-Pool, den Sie aktualisieren möchten, und wählen Sie ihn aus.
Klicken Sie auf
Zugriff erlauben, um Zugriff auf den ausgewählten Workload Identity-Pool zu gewähren.Wählen Sie in der Liste Dienstkonto das Dienstkonto aus, das von den externen Identitäten übernommen werden soll.
Führen Sie eine der folgenden Aktionen aus, um auszuwählen, welche Identitäten im Pool die Identität des Dienstkontos übernehmen können:
Damit nur bestimmte Identitäten des Workload Identity-Pools die Identität des Dienstkontos übernehmen können, wählen Sie Nur Identitäten, die dem Filter entsprechen aus.
Wählen Sie in der Liste Attributname das Attribut aus, nach dem Sie filtern möchten.
Geben Sie im Feld Attributwert den erwarteten Wert des Attributs ein. Wenn Sie beispielsweise eine Attributzuordnung
google.subject=assertion.sub
verwenden, legen Sie den Attributnamen aufsubject
und den Attributwert auf den Wert dersub
-Anforderung in Tokens fest, die von Ihrem externen Identitätsanbieter ausgestellt wurden.
Klicken Sie zum Speichern der Konfiguration auf Speichern und dann auf Schließen.
gcloud
So nutzen Sie die gcloud CLI, um externen Identitäten zu erlauben, die Identität eines Dienstkontos zu übernehmen:
Führen Sie den folgenden Befehl aus, um die Projektnummer Ihres aktuellen Projekts abzurufen:
gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)
So weisen Sie externen Identitäten, die bestimmte Kriterien erfüllen, die Rolle „Workload Identity-Nutzer“ (
roles/iam.workloadIdentityUser
) zu:Nach Thema
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/iam.workloadIdentityUser \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
Nach Gruppe
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/iam.workloadIdentityUser \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
Nach Attribut
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/iam.workloadIdentityUser \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
Ersetzen Sie Folgendes:
SERVICE_ACCOUNT_EMAIL
: die E-Mail-Adresse des Dienstkontos.PROJECT_NUMBER
: die Projektnummer des Projekts, das den Workload Identity-Pool enthältPOOL_ID
: die Pool-ID des Workload Identity-PoolsSUBJECT
: der erwartete Wert für das Attribut, das Siegoogle.subject
zugeordnet habenGROUP
: der erwartete Wert für das Attribut, das Siegoogle.groups
zugeordnet habenATTRIBUTE_NAME
: der Name eines benutzerdefinierten Attributs in Ihrer Attributzuordnung
Bereitstellungspipeline konfigurieren
Sie können die Workload Identity-Föderation in Ihrer Deployment-Pipeline jetzt verwenden.
Azure DevOps
Bearbeiten Sie die Datei azure-pipelines.yml
und fügen Sie der Jobkonfiguration Folgendes hinzu:
variables: - name: Azure.WorkloadIdentity.Connection value: CONNECTION - name: GoogleCloud.WorkloadIdentity.ProjectNumber value: PROJECT_NUMBER - name: GoogleCloud.WorkloadIdentity.Pool value: POOL_ID - name: GoogleCloud.WorkloadIdentity.Provider value: PROVIDER_ID - name: GoogleCloud.WorkloadIdentity.ServiceAccount value: SERVICE_ACCOUNT_EMAIL - name: GOOGLE_APPLICATION_CREDENTIALS value: $(Pipeline.Workspace)/.workload_identity.wlconfig steps: - task: AzureCLI@2 inputs: connectedServiceNameARM: $(Azure.WorkloadIdentity.Connection) addSpnToEnvironment: true scriptType: 'bash' scriptLocation: 'inlineScript' inlineScript: | echo $idToken > $(Pipeline.Workspace)/.workload_identity.jwt cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS { "type": "external_account", "audience": "//iam.googleapis.com/projects/$(GoogleCloud.WorkloadIdentity.ProjectNumber)/locations/global/workloadIdentityPools/$(GoogleCloud.WorkloadIdentity.Pool)/providers/$(GoogleCloud.WorkloadIdentity.Provider)", "subject_token_type": "urn:ietf:params:oauth:token-type:jwt", "token_url": "https://sts.googleapis.com/v1/token", "credential_source": { "file": "$(Pipeline.Workspace)/.workload_identity.jwt" }, "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$(GoogleCloud.WorkloadIdentity.ServiceAccount):generateAccessToken" } EOF
Ersetzen Sie die folgenden Werte:
CONNECTION
: der Name Ihrer DienstverbindungPROJECT_NUMBER
: die Projektnummer des Projekts, das den Workload Identity-Pool enthältPOOL_ID
: die ID des Workload Identity-PoolsPROVIDER_ID
: die ID des Workload Identity-PoolanbietersSERVICE_ACCOUNT_EMAIL
: die E-Mail-Adresse des Dienstkontos.
Die Konfiguration führt Folgendes aus:
- Ruft mit der Aufgabe
AzureCLI
ein ID-Token für die Dienstverbindung ab und stellt es in einer Variablen mit dem NamenidToken
zur Verfügung. - Speichert das ID-Token in einer temporären Datei mit dem Namen
.workload_identity.jwt
. - Erstellt eine Konfigurationsdatei für Anmeldedaten, die Clientbibliotheken anweist, das ID-Token aus
.workload_identity.jwt
zu lesen und damit die Identität eines Dienstkontos zu übernehmen. - Legt die Umgebungsvariable
GOOGLE_APPLICATION_CREDENTIALS
so fest, dass sie auf die Konfigurationsdatei für Anmeldedaten verweist.
GitHub Actions
Mit der Aktion google-github-actions/auth
können Sie während der Workflowausführung automatisch eine Konfigurationsdatei für Anmeldedaten generieren. Clientbibliotheken und Tools wie terraform
können diese Konfigurationsdatei für Anmeldedaten dann verwenden, um Google-Anmeldedaten automatisch zu erhalten.
Bearbeiten Sie Ihre YAML-Datei für GitHub Actions und fügen Sie Folgendes hinzu:
Erlauben Sie dem Job, ein GitHub-ID-Token durch Hinzufügen der folgenden Konfiguration abzurufen:
permissions: id-token: write contents: read
Fügen Sie einen Schritt zum Erstellen einer Konfigurationsdatei für Anmeldedaten hinzu:
- id: 'auth' name: 'Authenticate to Google Cloud' uses: 'google-github-actions/auth@v1' with: create_credentials_file: true workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID' service_account: 'SERVICE_ACCOUNT_EMAIL'
Ersetzen Sie die folgenden Werte:
PROJECT_NUMBER
: die Projektnummer des Projekts, das den Workload Identity-Pool enthältPOOL_ID
: die ID des Workload Identity-PoolsPROVIDER_ID
: die ID des Workload Identity-PoolanbietersSERVICE_ACCOUNT_EMAIL
: die E-Mail-Adresse des Dienstkontos.
Beispiel:
jobs: build: # Allow the job to fetch a GitHub ID token permissions: id-token: write contents: read runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - id: 'auth' name: 'Authenticate to Google Cloud' uses: 'google-github-actions/auth@v1' with: create_credentials_file: true workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID' service_account: 'SERVICE_ACCOUNT_EMAIL'
Weitere Informationen zur Verwendung der Aktion google-github-actions/auth
finden Sie unter Identitätsföderation von Arbeitslasten einrichten.
GitLab SaaS
Bearbeiten Sie die Datei .gitlab-ci.yml
und fügen Sie der Jobkonfiguration Folgendes hinzu:
job: variables: WORKLOAD_IDENTITY_PROJECT_NUMBER: PROJECT_NUMBER WORKLOAD_IDENTITY_POOL: POOL_ID WORKLOAD_IDENTITY_PROVIDER: PROVIDER_ID SERVICE_ACCOUNT: SERVICE_ACCOUNT_EMAIL GOOGLE_APPLICATION_CREDENTIALS: $CI_BUILDS_DIR/.workload_identity.wlconfig id_tokens: WORKLOAD_IDENTITY_TOKEN: aud: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID script: - |- echo $WORKLOAD_IDENTITY_TOKEN > $CI_BUILDS_DIR/.workload_identity.jwt cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS { "type": "external_account", "audience": "//iam.googleapis.com/projects/$WORKLOAD_IDENTITY_PROJECT_NUMBER/locations/global/workloadIdentityPools/$WORKLOAD_IDENTITY_POOL/providers/$WORKLOAD_IDENTITY_PROVIDER", "subject_token_type": "urn:ietf:params:oauth:token-type:jwt", "token_url": "https://sts.googleapis.com/v1/token", "credential_source": { "file": "$CI_BUILDS_DIR/.workload_identity.jwt" }, "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$SERVICE_ACCOUNT:generateAccessToken" } EOF
Ersetzen Sie die folgenden Werte:
PROJECT_NUMBER
: die Projektnummer des Projekts, das den Workload Identity-Pool enthältPOOL_ID
: die ID des Workload Identity-PoolsPROVIDER_ID
: die ID des Workload Identity-PoolanbietersSERVICE_ACCOUNT_EMAIL
: die E-Mail-Adresse des Dienstkontos.
Die Konfiguration führt Folgendes aus:
- Weisen Sie GitLab an, ein ID-Token auszustellen und in der Umgebungsvariablen namens
WORKLOAD_IDENTITY_TOKEN
verfügbar zu machen. Das ID-Token verwendet den Workload Identity-Poolanbieter als Zielgruppe. - Speichern Sie das ID-Token in einer temporären Datei namens
.workload_identity.jwt
. - Erstellen Sie eine Konfigurationsdatei für Anmeldedaten, die Clientbibliotheken anweist, das ID-Token aus
.workload_identity.jwt
zu lesen und dessen Identität zu übernehmen. - Legen Sie die Umgebungsvariable
GOOGLE_APPLICATION_CREDENTIALS
so fest, dass sie auf die Konfigurationsdatei für Anmeldedaten verweist.
Terraform Cloud
Konfigurieren Sie Ihren Terraform Cloud-Arbeitsbereich so, dass er die Identitätsföderation von Arbeitslasten zur Authentifizierung bei Google Cloud verwendet:
Öffnen Sie in Terraform Cloud Ihren Arbeitsbereich und rufen Sie Variablen auf.
Fügen Sie die folgenden Variablen hinzu:
Variablenkategorie Schlüssel Wert Umgebungsvariable TFC_GCP_PROVIDER_AUTH
true
Umgebungsvariable TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL
Die E-Mail-Adresse des Dienstkontos, z. B. terraform@my-project-123.iam.gserviceaccount.com
.Umgebungsvariable TFC_GCP_PROJECT_NUMBER
Die Projektnummer des Projekts, das den Workload Identity-Pool enthält Umgebungsvariable TFC_GCP_WORKLOAD_POOL_ID
Die ID des Workload Identity-Pools Umgebungsvariable TFC_GCP_WORKLOAD_PROVIDER_ID
Die ID des Workload Identity-Poolanbieters Optional können Sie zusätzliche Umgebungsvariablen hinzufügen, damit Terraform Cloud verschiedene Dienstkonten für die Phasen
plan
undapply
verwendet. Weitere Informationen finden Sie unter Optionale Umgebungsvariablen.Prüfen Sie in der Liste der Variablen, ob für die Kategorie der Wert
env
für die fünf Variablen festgelegt ist, die Sie im vorherigen Schritt hinzugefügt haben.Prüfen Sie, ob Ihre Terraform-Konfiguration Version
4.48.0
oder höher des Google Cloud-Anbieters verwendet, und aktualisieren Sie sie bei Bedarf so:terraform { required_providers { google = { source = "hashicorp/google" version = "~> 4.48.0" } } }
Senden Sie die Änderungen an Ihr Quellcode-Repository.
Nächste Schritte
- Weitere Informationen zur Workload Identity-Föderation
- Best Practices für die Verwendung der Workload Identity-Föderation in Bereitstellungspipelines
- Workload Identity-Pools und -Anbieter verwalten