Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Workload Identity-Föderation mit Bereitstellungspipelines konfigurieren

In diesem Leitfaden wird beschrieben, wie Sie mit Workload Identity-Föderation Bereitstellungspipelines bei Google Cloudauthentifizieren.

Je nach verwendetem CI/CD-System haben Ihre Bereitstellungspipelines möglicherweise Zugriff auf umgebungsspezifische Anmeldedaten. Beispiel:

Azure DevOps-Pipelines können eine Microsoft Entra-Dienstverbindung zur Workload Identity-Föderation 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.
HCP Terraform kann Ihrer Terraform-Konfiguration ein OIDC-Token zur Verfügung stellen, das den Arbeitsbereich und die Umgebung eindeutig identifiziert.

Sie können Ihre Bereitstellungspipelines so konfigurieren, dass sie diese Anmeldedaten zur Authentifizierung beiGoogle Cloud mithilfe der Identitätsföderation von Arbeitslasten verwenden. Bei diesem Ansatz entfallen die mit Dienstkontoschlüsseln verbundenen Wartungs- und Sicherheitsaufwand.

Hinweise

Authentifizierung einrichten

Wählen Sie den Tab aus, der Ihrer geplanten Verwendung der Beispiele auf dieser Seite entspricht:

Console

Wenn Sie über die Google Cloud Console auf Google Cloud Dienste und APIs zugreifen, müssen Sie die Authentifizierung nicht einrichten.

gcloud

Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

Python

Wenn Sie die Python-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung verwenden möchten, installieren und initialisieren Sie die gcloud CLI und richten Sie dann die Standardanmeldedaten für Anwendungen mit Ihren Nutzeranmeldedaten ein.

Installieren Sie die Google Cloud CLI.
Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.
Wenn Sie eine lokale Shell verwenden, erstellen Sie lokale Anmeldedaten zur Authentifizierung für Ihr Nutzerkonto:
```
gcloud auth application-default login
```
Wenn Sie Cloud Shell verwenden, müssen Sie das nicht tun.

Wenn ein Authentifizierungsfehler zurückgegeben wird und Sie einen externen Identitätsanbieter (IdP) verwenden, prüfen Sie, ob Sie sich mit Ihrer föderierten Identität in der gcloud CLI angemeldet haben.

Weitere Informationen finden Sie in der Dokumentation zur Google Cloud -Authentifizierung unter ADC für eine lokale Entwicklungsumgebung einrichten.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Workload Identity-Pool-Admin (roles/iam.workloadIdentityPoolAdmin) für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Konfigurieren der Identitätsföderation von Arbeitslasten benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen 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 Cloudauthentifizieren kann, müssen Sie zuerst eine Dienstverbindung für Azure Resource Manager konfigurieren. Über diese Verbindung kann die Pipeline ein ID-Token abrufen, das sie dann gegenGoogle Cloud -Anmeldedaten eintauschen kann.

So erstellen Sie eine Dienstverbindung für Azure Resource Manager:

Öffnen Sie in Azure DevOps Ihr Projekt und rufen Sie die Projekteinstellungen auf.
Rufen Sie Pipelines > Dienstverbindungen auf.
Klicken Sie auf Dienstverbindung erstellen.
Wählen Sie Azure Resource Manager aus.
Klicken Sie auf Weiter.
Legen Sie folgende Einstellungen fest:
- Identitätstyp: App-Registrierung (automatisch)
- Anmeldedaten: Workload Identity-Föderation
- Bereichsebene: Abo.
  
  Sie müssen ein Abo auswählen, auch wenn Sie nicht planen, mit der Dienstverbindung auf Azure-Ressourcen zuzugreifen.
- Name der Dienstverbindung: Geben Sie einen Namen wie google-cloud ein.
Klicken Sie auf Speichern.
Suchen Sie unter Details zur Identitätsföderation von Arbeitslasten nach den folgenden Kennungen:
- Aussteller: eindeutiger Bezeichner Ihrer Azure DevOps-Organisation
- Subjekt-ID: Identifiziert die Dienstverbindung eindeutig.
Speichern Sie diese Kennungen für einen der nächsten Schritte.

Azure DevOps gewährt dem Diensthauptkonto der Dienstverbindung automatisch Zugriff auf das von Ihnen ausgewählte Azure-Abo. Wir empfehlen Ihnen, den Zugriff zu reduzieren, indem Sie Folgendes tun:

Klicken Sie auf Rollen für Dienstverbindungen verwalten.
Klicken Sie auf Rollenzuweisungen.
Suchen Sie die Rollenzuweisung für die Dienstverbindung und entfernen Sie sie oder ersetzen Sie sie durch eine Rollenzuweisung mit einer Rolle mit weniger Berechtigungen.

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 so konfiguriert haben, dass er Ihrer GitLab-Gruppe vertraut, können Sie die Workload Identity-Föderation für einzelne CI/CD-Jobs aktivieren.

HCP Terraform

Sie müssen keine Änderungen an der Konfiguration in Ihrem HCP Terraform-Konto vornehmen.

Nachdem Sie einen Workload Identity-Pool für die Vertrauensstellung von HCP Terraform konfiguriert haben, können Sie die Workload Identity-Föderation für einzelne Arbeitsbereiche aktivieren.

Identitätsföderation von Arbeitslasten konfigurieren

Führen Sie diese Schritte für jedes Azure DevOps-Projekt, jede GitHub-Organisation, jede GitLab-Gruppe oder jede HCP Terraform-Organisation aus.

So konfigurieren Sie die Workload Identity-Föderation:

Wählen Sie in der Google Cloud Console auf der Seite für die Projektauswahl ein Google Cloud -Projekt aus oder erstellen Sie eines.
Rollen, die zum Auswählen oder Erstellen eines Projekts erforderlich sind
- Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können jedes Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
- Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator), die die Berechtigung resourcemanager.projects.create enthält. Weitere Informationen zum Zuweisen von Rollen
Zur Projektauswahl

ein dediziertes Projekt zum Verwalten von Workload Identity-Pools und -Anbietern zu verwenden

Prüfen Sie, ob für Ihr Google Cloud Projekt die Abrechnung aktiviert ist.

Aktivieren Sie die IAM API, die Resource Manager API, die Service Account Credentials API und die Security Token Service API.

Rollen, die zum Aktivieren von APIs erforderlich sind

Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen

APIs aktivieren

Attributzuordnung definieren

Die umgebungsspezifischen Anmeldedaten Ihrer Bereitstellungspipeline können mehrere Attribute enthalten. Sie müssen entscheiden, welches Attribut Sie in Google Cloudals 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 mit der Subjekt-ID Ihrer Dienstverbindung. Die Subjekt-ID hat folgendes Format:

PREFIX/sc/SERVICE_CONNECTION

Die Länge dieser Betreff-ID überschreitet 127 Zeichen. Das ist die maximal zulässige Länge für google.subject. Um diese Einschränkung zu umgehen, verwenden Sie die folgende Attributzuordnung:

google.subject=assertion.sub.extract('/sc/{service_connection}')

Bei dieser Zuordnung wird der Teil der sub-Anforderung nach /sc/ als Subjekt verwendet, das die Dienstverbindung innerhalb des Entra-Mandanten eindeutig identifiziert.

GitHub Actions

Ihre Attributzuordnungen können beliebige Anforderungen im OIDC-Token von GitHub Actions verwenden. Diese Schlüssel für die Token-Anforderung und ihre Werte werden von GitHub verwaltet. 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 Attribute von Anforderungen 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 ist eine Teilmenge der möglichen Anforderungen. Eine vollständige Liste finden Sie in der GitHub-Dokumentation unter Beispielanforderungen. Achten Sie darauf, alle Ansprüche 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, auf die sich der Job bezieht.
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 reicht es möglicherweise aus, 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

HCP Terraform

Ihre Attributzuordnungen können die im OIDC-Token von HCP Terraform 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 HCP Terraform 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. Sie benötigen eine Attributzuordnung für alle Felder mit Attributbedingungen.

Azure DevOps

Sie müssen keine Attributbedingung konfigurieren, da Azure DevOps eine mandantenspezifische Aussteller-URL verwendet.

GitHub Actions

Verwenden Sie die folgende Attributbedingung, um den Zugriff auf Tokens einzuschränken, die von Ihrer GitHub-Organisation ausgegeben wurden:

assertion.repository_owner=='ORGANIZATION'

Ersetzen Sie 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 ausgegeben wurden.

assertion.namespace_id=='GROUP_ID'

Ersetzen Sie GROUP_ID durch die Gruppen-ID, die auf der Startseite Ihrer GitLab-Gruppe angezeigt wird.

Optional können Sie die Attributbedingung erweitern, um den Zugriff auf eine Teilmenge von Projekten, Zweigen oder Umgebungen zu beschränken. Die folgende Bedingung begrenzt beispielsweise den Zugriff auf Jobs, die die Umgebung production verwenden:

assertion.namespace_id=='GROUP_ID' && assertion.environment=='production'

HCP Terraform

Verwenden Sie die folgende Attributbedingung, um den Zugriff auf von Ihrer HCP Terraform-Organisation ausgegebene Tokens einzuschränken:

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' && assertion.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.

Zum neuen Arbeitslastanbieter und -anbieterpool
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).
- Providername: 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 geben Sie den folgenden Wert ein:
  
  fb60f99c-7a34-4190-8149-302f77469936
  
  Diese ID ist die Anwendungs-ID des Azure Token Exchange-Endpunkts.
GitHub Actions
- Anbieter auswählen: OpenID Connect (OIDC).
- Name des Anbieters: Name des Anbieters.
- Anbieter-ID: ID für den Anbieter. 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 für den Anbieter. Sie können die Anbieter-ID später nicht mehr ändern.
- Aussteller-URL: https://gitlab.com
- Zielgruppen: Standardzielgruppe
HCP Terraform
- Anbieter auswählen: OpenID Connect (OIDC).
- Name des Anbieters: Name des Anbieters.
- Anbieter-ID: ID für den Anbieter. 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 Pools
- DISPLAY_NAME: der Name des Pools
- DESCRIPTION: 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" \ --allowed-audiences="api://AzureADTokenExchange" \ --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 haben
- CONDITIONS: 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/" \ --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: 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 Anbieters
- POOL_ID: die ID des Pools.
- MAPPINGS: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben
- CONDITIONS: die zuvor identifizierte Attributbedingung
HCP Terraform
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 Provider aktualisieren

In diesem Abschnitt wird beschrieben, wie Sie die Attributbedingung für einen vorhandenen Workload Identity-Pool-Anbieter aktualisieren können, um den Zugriff auf Tokens einzuschränken, die von Ihrer GitHub-Organisation, GitLab-Gruppe oder HCP Terraform-Organisation ausgegeben wurden.

Die empfohlene Attributbedingung für Ihre Pipeline finden Sie unter Attributbedingung definieren.

Console

Rufen Sie in der Google Cloud Console die Seite Workload Identity-Pools auf.

Zu Workload Identity-Pools
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 den folgenden Befehl aus, um den Workload Identity-Pool-Anbieter 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 Anbieters
POOL_ID: die ID des Pools.
CONDITIONS: zuvor identifizierte Attributbedingung.

Deployment-Pipeline authentifizieren

Sie müssen diese Schritte für jeden GitHub Actions-Workflow oder Terraform Cloud-Arbeitsbereich ausführen.

Externer Arbeitslast den Zugriff auf Google Cloud -Ressourcen erlauben

Damit Ihre Arbeitslast auf Google Cloud -Ressourcen zugreifen kann, empfehlen wir, dem Prinzipal direkten Ressourcenzugriff zu gewähren. In diesem Fall ist das Hauptkonto der föderierte Nutzer. Für einige Google Cloud Produkte gelten Einschränkungen für Google Cloud APIs. Wenn Ihre Arbeitslast einen API-Endpunkt aufruft, der eingeschränkt ist, können Sie stattdessen die Identitätsübernahme des Dienstkontos verwenden. In diesem Fall ist das Hauptkonto dasGoogle Cloud -Dienstkonto, das als Identität fungiert. Sie gewähren dem Dienstkonto Zugriff auf die Ressource.

Direkter Ressourcenzugriff

Sie können einer föderierten Identität direkt Zugriff auf Ressourcen gewähren, indem Sie die Google Cloud Console oder die gcloud CLI verwenden.

Console

Wenn Sie in der Google Cloud Console IAM-Rollen direkt für eine Ressource zuweisen möchten, müssen Sie die Seite der Ressource aufrufen und dann die Rolle zuweisen. Im folgenden Beispiel wird gezeigt, wie Sie zur Cloud Storage-Seite wechseln und einer föderierten Identität direkt für einen Cloud Storage-Bucket die Rolle „Storage-Objekt-Betrachter“ (roles/storage.objectViewer) zuweisen.

Wechseln Sie in der Google Cloud Console unter „Cloud Storage“ zur Seite Buckets.

Buckets aufrufen
Klicken Sie in der Liste der Buckets auf den Namen des Buckets, für den Sie die Rolle zuweisen möchten.
Wählen Sie oben auf der Seite den Tab Berechtigungen aus.
Klicken Sie auf den Button Zugriff gewähren.

Das Dialogfeld Hauptkonten hinzufügen wird angezeigt.
Geben Sie in das Feld Neue Hauptkonten eine oder mehrere Identitäten ein, die Zugriff auf den Bucket erhalten sollen.
Nach Subjekt
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
Ersetzen Sie Folgendes:
- PROJECT_NUMBER: die Projektnummer
- POOL_ID: die ID des Arbeitslastpools
- SUBJECT: das einzelne Thema, das Ihrem IdP zugeordnet ist, z. B. administrator@example.com
Nach Gruppe
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
Ersetzen Sie Folgendes:
- PROJECT_NUMBER: die Projektnummer
- WORKLOAD_POOL_ID: die ID des Arbeitslastpools
- GROUP: die Gruppe, die Ihrem IdP zugeordnet ist, z. B. administrator-group@example.com
Nach Attribut
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Ersetzen Sie Folgendes:
- PROJECT_NUMBER: die Projektnummer
- WORKLOAD_POOL_ID: die ID des Arbeitslastpools
- ATTRIBUTE_NAME: eines der Attribute, die von Ihrem IdP zugeordnet wurden.
- ATTRIBUTE_VALUE: der Wert des Attributs
Wählen Sie aus dem Drop-down-Menü Rolle auswählen eine oder mehrere Rollen aus. Die ausgewählten Rollen werden in der Ansicht mit einer kurzen Beschreibung ihrer jeweiligen Berechtigungen angezeigt.
Klicken Sie auf Speichern.

gcloud

So weisen Sie mit der gcloud CLI IAM-Rollen für eine Ressource in einem Projekt zu:

Rufen Sie die Projektnummer des Projekts ab, in dem die Ressource definiert ist.

gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)

Gewähren Sie Zugriff auf die Ressource.

Führen Sie den folgenden Befehl aus, um mit der gcloud CLI externen Identitäten, die bestimmte Kriterien erfüllen, die Rolle „Storage-Objekt-Betrachter“ (roles/storage.objectViewer) zuzuweisen.
Nach Thema
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
```
Nach Gruppe
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
```
Nach Attribut
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
```
Ersetzen Sie Folgendes:
- BUCKET_ID: der Bucket, für den Zugriff gewährt werden soll
- PROJECT_NUMBER: die Projektnummer des Projekts, das den Workload Identity-Pool enthält
- POOL_ID: die Pool-ID des Workload Identity-Pools
- SUBJECT: der erwartete Wert für das Attribut, das Sie google.subject zugeordnet haben
- GROUP: der erwartete Wert für das Attribut, das Sie google.groups zugeordnet haben
- ATTRIBUTE_NAME: der Name eines benutzerdefinierten Attributs in Ihrer Attributzuordnung
- ATTRIBUTE_VALUE: Wert des benutzerdefinierten Attributs in Ihrer Attributzuordnung
Sie können jeder Google Cloud Ressource, die IAM-Zulassungsrichtlinien unterstützt, Rollen zuweisen.
Hinweis: Sie müssen in der Mitglieds-ID die Projektnummer, nicht die Projekt-ID, verwenden.

Identitätsübertragung für ein Dienstkonto

So erstellen Sie ein Dienstkonto für die externe Arbeitslast:
1. Aktivieren Sie die IAM API, die Security Token Service API und die Service Account Credentials API.
  Rollen, die zum Aktivieren von APIs erforderlich sind
  Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen
  APIs aktivieren
2. Erstellen Sie ein Dienstkonto, das die Arbeitslast darstellt. Wir empfehlen, für jede Arbeitslast ein dediziertes Dienstkonto zu verwenden. Das Dienstkonto muss sich nicht im selben Projekt wie der Workload Identity-Pool befinden. Sie müssen sich aber auf das Projekt beziehen, das das Dienstkonto enthält.
3. Gewähren Sie dem Dienstkonto Zugriff auf Ressourcen, auf die externe Identitäten zugreifen können sollen.
Damit die föderierte Identität die Identität des Dienstkontos übernehmen kann, gehen Sie so vor:

Console

So weisen Sie der Google Cloud Console IAM-Rollen zu, um einer föderierten Identität mit einem Dienstkonto IAM-Rollen zuzuweisen:

Dienstkonto im selben Projekt

So gewähren Sie einem Dienstkonto im selben Projekt Zugriff über die Identitätsübernahme des Dienstkontos:
1. Rufen Sie die Seite Workload Identity-Pools auf.
  
  Zu Workload Identity-Pools
2. Wählen Sie Zugriff gewähren aus.
3. Wählen Sie im Dialogfeld Zugriff auf Dienstkonto gewähren die Option Zugriff mit Identitätsübernahme des Dienstkontos gewähren aus.
4. Wählen Sie in der Liste Dienstkonten das Dienstkonto aus, das von den externen Identitäten übernommen werden soll. Gehen Sie dann so vor:
5. 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 google.subject=assertion.sub-Attributzuordnung verwenden, legen Sie den Attributnamen auf subject und den Attributwert auf den Wert der sub-Anforderung in Tokens fest, die von Ihrem externen Identitätsanbieter ausgestellt werden.
6. Klicken Sie zum Speichern der Konfiguration auf Speichern und dann auf Schließen.

Dienstkonto in einem anderen Projekt

So gewähren Sie einem Dienstkonto in einem anderen Projekt Zugriff über die Identitätsübernahme des Dienstkontos:
1. Rufen Sie die Seite Dienstkonten auf.
  
  Zur Seite „Dienstkonten“
2. Wählen Sie das Dienstkonto aus, dessen Identität Sie übernehmen möchten.
3. Klicken Sie auf Zugriff verwalten.
4. Klicken Sie auf Hauptkonto hinzufügen.
5. Geben Sie im Feld Neues Hauptkonto eine der folgenden Hauptkonto-IDs für die Identitäten in Ihrem Pool ein, die die Identität des Dienstkontos übernehmen.
  Nach Thema
  principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
  
  Ersetzen Sie Folgendes:
  
  PROJECT_NUMBER: die Projektnummer
  
  POOL_ID: die ID des Arbeitslastpools
  
  SUBJECT: das einzelne Thema, das Ihrem IdP zugeordnet ist, z. B. administrator@example.com
  Nach Gruppe
  principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
  
  Ersetzen Sie Folgendes:
  
  PROJECT_NUMBER: die Projektnummer
  
  WORKLOAD_POOL_ID: die ID des Arbeitslastpools
  
  GROUP: die Gruppe, die Ihrem IdP zugeordnet ist, z. B. administrator-group@example.com
  Nach Attribut
  principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
  
  Ersetzen Sie Folgendes:
  
  PROJECT_NUMBER: die Projektnummer
  
  WORKLOAD_POOL_ID: die ID des Arbeitslastpools
  
  ATTRIBUTE_NAME: eines der Attribute, die von Ihrem IdP zugeordnet wurden.
  
  ATTRIBUTE_VALUE: der Wert des Attributs
  Nach Pool
  principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
  
  Ersetzen Sie Folgendes:
  
  PROJECT_NUMBER: die Projektnummer
  
  WORKLOAD_POOL_ID: die ID des Arbeitslastpools
6. Wählen Sie unter Rolle auswählen die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) aus.
7. Klicken Sie auf Speichern, um die Konfiguration zu speichern.

gcloud

Führen Sie den folgenden Befehl aus, um einem föderierten Prinzipal oder einer Gruppe von Prinzipalen die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) zuzuweisen. Weitere Informationen zu Hauptkonto-IDs für die Workload Identity-Föderation finden Sie unter Hauptkontotypen.

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ält
POOL_ID: die Pool-ID des Workload Identity-Pools
SUBJECT: der erwartete Wert für das Attribut, das Sie google.subject zugeordnet haben
GROUP: der erwartete Wert für das Attribut, das Sie google.groups zugeordnet haben
ATTRIBUTE_NAME: der Name eines benutzerdefinierten Attributs in Ihrer Attributzuordnung
ATTRIBUTE_VALUE: Wert des benutzerdefinierten Attributs in Ihrer Attributzuordnung

Bereitstellungspipeline konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie Workload Identity-Föderation in Ihrer Bereitstellungspipeline verwenden. In der Anleitung in diesem Abschnitt wird davon ausgegangen, dass Ihre Arbeitslasten die Identitätsübernahme des Dienstkontos für den Zugriff auf Google Cloud-Ressourcen 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.REGION.rep.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 Dienstverbindung.
PROJECT_NUMBER: Die Projektnummer des Projekts, das den Workload Identity-Pool enthält.
POOL_ID: die ID des Workload Identity-Pools.
PROVIDER_ID: die ID des Anbieters des Workload Identity-Pools.
SERVICE_ACCOUNT_EMAIL: Die E-Mail-Adresse des Dienstkontos, wenn Sie die Identitätsübernahme des Dienstkontos verwenden. Wenn Sie den direkten Ressourcenzugriff verwenden, lassen Sie GoogleCloud.WorkloadIdentity.ServiceAccount und service_account_impersonation_url weg.
REGION: Eine Region für regionale STS-Endpunkte, sofern verfügbar. Wenn regionale Endpunkte nicht verfügbar sind, können Sie https://sts.googleapis.com/v1/token verwenden.

Die Konfiguration hat folgende Auswirkungen:

Verwendet die Aufgabe AzureCLI, um ein ID-Token für die Dienstverbindung abzurufen und in einer Variablen namens idToken verfügbar zu machen.
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 von .workload_identity.jwt zu lesen und es zum Übernehmen der Identität eines Dienstkontos zu verwenden.
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 Folgendes:

PROJECT_NUMBER: die Projektnummer des Projekts, das den Workload Identity-Pool enthält.
POOL_ID: die ID des Workload Identity-Pools.
PROVIDER_ID: die ID des Workload Identity-Poolanbieters.
SERVICE_ACCOUNT_EMAIL: Die E-Mail-Adresse des Dienstkontos, wenn Sie die Identitätsübernahme des Dienstkontos verwenden. Wenn Sie den direkten Ressourcenzugriff verwenden, lassen Sie service_account weg.

Im folgenden Beispiel wird die GitHub-Aktion konfiguriert:

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.REGION.rep.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ält.
POOL_ID: die ID des Workload Identity-Pools.
PROVIDER_ID: die ID des Anbieters des Workload Identity-Pools.
SERVICE_ACCOUNT_EMAIL: Die E-Mail-Adresse des Dienstkontos, wenn Sie die Identitätsübernahme des Dienstkontos verwenden. Wenn Sie den direkten Ressourcenzugriff verwenden, lassen Sie SERVICE_ACCOUNT und service_account_impersonation_url weg.
REGION: Eine Region für regionale STS-Endpunkte, sofern verfügbar. Wenn regionale Endpunkte nicht verfügbar sind, können Sie https://sts.googleapis.com/v1/token verwenden.

Die Konfiguration hat folgende Auswirkungen:

Weist GitLab an, ein ID-Token auszugeben und es in der Umgebungsvariablen mit dem Namen WORKLOAD_IDENTITY_TOKEN verfügbar zu machen. Das ID-Token verwendet Ihren Anbieter des Workload Identity-Pools als Zielgruppe.
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 von .workload_identity.jwt zu lesen und es zum Übernehmen der Identität eines Dienstkontos zu verwenden.
Legt die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS so fest, dass sie auf die Konfigurationsdatei für Anmeldedaten verweist.

HCP Terraform

Konfigurieren Sie Ihren HCP Terraform-Arbeitsbereich so, dass er die Workload Identity-Föderation verwendet, um sich über die Identitätsübernahme des Dienstkontos bei Google Cloud zu authentifizieren:

Öffnen Sie in HCP Terraform Ihren Arbeitsbereich und rufen Sie Variables 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, wenn Sie die Identitätsübernahme des Dienstkontos verwenden, 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 HCP Terraform verschiedene Dienstkonten für die Phasen plan und apply verwendet. Weitere Informationen zum Verwenden von Umgebungsvariablen in Terraform-Konfigurationen finden Sie unter Optionale Umgebungsvariablen.

Prüfen Sie in der Liste der Variablen, ob Category für die fünf Variablen, die Sie im vorherigen Schritt hinzugefügt haben, auf env festgelegt ist.
Prüfen Sie, ob Ihre Terraform-Konfiguration Version 4.48.0 oder höher des Google Cloud -Bereitstellers verwendet, und aktualisieren Sie sie bei Bedarf so:
```
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.48.0"
    }
  }
}
```
Übernehmen Sie die Änderungen in Ihr Quellcode-Repository.

Workload Identity-Föderation mit Bereitstellungspipelines konfigurieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweise

Authentifizierung einrichten

Console

gcloud

Python

Erforderliche Rollen

Externen IdP vorbereiten

Azure DevOps

GitHub Actions

GitLab SaaS

HCP Terraform

Identitätsföderation von Arbeitslasten konfigurieren

Attributzuordnung definieren

Azure DevOps

GitHub Actions

GitLab SaaS

HCP Terraform

Attributbedingung definieren

Azure DevOps

GitHub Actions

GitLab SaaS

HCP Terraform

Workload Identity-Pool und -Anbieter erstellen

Console

Azure DevOps

GitHub Actions

GitLab SaaS

HCP Terraform

gcloud

Azure DevOps

GitHub Actions

GitLab SaaS

HCP Terraform

Attributbedingung für einen Workload Identity Provider aktualisieren

Console

gcloud

Deployment-Pipeline authentifizieren

Externer Arbeitslast den Zugriff auf Google Cloud -Ressourcen erlauben

Direkter Ressourcenzugriff

Console

Nach Subjekt

Nach Gruppe

Nach Attribut

gcloud

Nach Thema

Nach Gruppe

Nach Attribut

Identitätsübertragung für ein Dienstkonto

Console

Dienstkonto im selben Projekt

Dienstkonto in einem anderen Projekt

Nach Thema

Nach Gruppe

Nach Attribut

Nach Pool

gcloud

Nach Thema

Nach Gruppe

Nach Attribut

Bereitstellungspipeline konfigurieren

Azure DevOps

GitHub Actions

GitLab SaaS

HCP Terraform

Nächste Schritte

Workload Identity-Föderation mit Bereitstellungspipelines konfigurieren