Workload Identity-Föderation mit Bereitstellungspipelines konfigurieren

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:

1. Öffnen Sie in Azure DevOps Ihr Projekt und rufen Sie Project Settings (Projekteinstellungen) auf.
2. Rufen Sie Pipelines > Dienstverbindungen auf.
3. Klicken Sie auf Dienstverbindung erstellen.
4. Wählen Sie Azure Resource Manager aus.
5. Klicken Sie auf Next (Weiter).
6. Wählen Sie Workload Identity-Föderation (automatisch) aus.
7. Klicken Sie auf Next (Weiter).

8. 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.

9. Klicken Sie auf Speichern.

In einem späteren Schritt benötigen Sie die Aussteller- und Subjekt-ID der Dienstverbindung. So finden Sie diese Details:

1. Klicken Sie auf die Dienstverbindung, die Sie gerade erstellt haben.
2. Klicken Sie auf Diensthauptkonto verwalten.
3. Rufen Sie Zertifikat & Secrets > Föderierte Anmeldedaten auf.
4. Klicken Sie auf die föderierten Anmeldedaten.

5. 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:

1. Öffnen Sie im Azure-Portal das Abo, das Sie als Bereich ausgewählt haben.
2. Gehen Sie zu Zugriffssteuerung (IAM) > Rollenzuweisungen.
3. 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 so konfiguriert haben, dass er Ihrer GitLab-Gruppe vertraut, 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 Workload Identity-Föderation für einzelne Arbeitsbereiche aktivieren.

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 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.

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-Organisation
• PROJECT: 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'

Console

1. Rufen Sie in der Google Cloud Console die Seite Neuer Arbeitslastanbieter und -Pool auf.

   Zum neuen Arbeitslastanbieter und -anbieterpool

2. 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.

3. Klicken Sie auf Weiter.

4. 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

5. Klicken Sie auf Weiter.

6. Fügen Sie unter Anbieterattribute konfigurieren die zuvor identifizierten Attributzuordnungen hinzu.

7. Geben Sie unter Attributbedingungen die zuvor identifizierte Attributbedingung ein.

8. Klicken Sie auf Speichern, um den Workload Identity-Pool und -Poolanbieter zu erstellen.

gcloud

1. 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.

2. 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 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/" \
       --allowed-audiences="api://AzureADTokenExchange" \
       --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

   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.

Console

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

   Zu Workload Identity-Pools

2. Suchen Sie nach dem Workload Identity-Pool, der den Anbieter enthält, und klicken Sie dann auf das Symbol arrow_right Knoten für den Pool maximieren.

3. Suchen Sie den Workload Identity-Poolanbieter, den Sie bearbeiten möchten, und klicken Sie auf edit Bearbeiten.

4. Geben Sie unter Attributbedingungen die zuvor identifizierte Attributbedingung ein.

5. 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 Anbieters
• POOL_ID: die ID des Pools.
• CONDITIONS: zuvor identifizierte Attributbedingung.

Direkter Ressourcenzugriff

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

Identitätsübertragung für ein Dienstkonto

1. So erstellen Sie ein Dienstkonto für die externe Arbeitslast:

   1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.

      Enable the APIs

   2. Erstellen Sie ein Dienstkonto, das die Arbeitslast darstellt. Es empfiehlt sich, für jede Arbeitslast ein dediziertes Dienstkonto zu verwenden.

      Das Dienstkonto muss sich nicht im selben Projekt wie der Workload Identity-Pool befinden.

   3. Gewähren Sie dem Dienstkonto Zugriff auf Ressourcen, auf die externe Identitäten zugreifen können sollen.

   4. Weisen Sie dem Dienstkonto die Nutzerrolle "Workload Identity" (roles/iam.workloadIdentityUser) zu.

   5. 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.

2. So gewähren Sie Zugriff auf eine föderierte Identität mithilfe der Identitätsübernahme des Dienstkontos über die Google Cloud Console oder die gcloud CLI:

   Console

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

   1. Erstellen Sie ein Dienstkonto, das als Identität für die Identitätsübernahme dient. Gehen Sie dazu so vor:

      1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.

         Enable the APIs

      2. Erstellen Sie ein Dienstkonto, das die Identität für 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. Wenn Sie jedoch IAM-Zugriff gewähren, müssen Sie auf das Projekt verweisen, das das Dienstkonto enthält.

      3. Gewähren Sie dem Dienstkonto Zugriff auf Ressourcen, auf die externe Identitäten zugreifen können sollen.

   2. So gewähren Sie Zugriff über die Dienstkonto-Identitätsübernahme:

      1. Rufen Sie die Seite Workload Identity-Pools auf.

         Zu Workload Identity-Pools

      2. Wählen Sie Zugriff erlauben 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 -subAnforderung in Tokens fest, die von Ihrem externen Identitätsanbieter ausgestellt wurden.

      6. Klicken Sie zum Speichern der Konfiguration auf Speichern und dann auf Schließen.

   gcloud

   Führen Sie den folgenden Befehl aus, um mit der gcloud CLI externen Identitäten, die bestimmte Kriterien erfüllen, die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) zuzuweisen.

   Nach Thema

   gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
       --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 SERVICE_ACCOUNT_EMAIL \
       --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 SERVICE_ACCOUNT_EMAIL \
       --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:

   • 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

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 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 Workload Identity-Poolanbieters
• SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos.

Die Konfiguration führt Folgendes aus:

1. Ruft mit der Aufgabe AzureCLI ein ID-Token für die Dienstverbindung ab und stellt es in einer Variablen mit dem Namen idToken zur Verfügung.
2. Speichert das ID-Token in einer temporären Datei mit dem Namen .workload_identity.jwt.
3. 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.
4. 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ält.
• POOL_ID: die ID des Workload Identity-Pools.
• PROVIDER_ID: die ID des Anbieters des Workload Identity-Pools.
• SERVICE_ACCOUNT_EMAIL: Ersetzen Sie die E-Mail-Adresse des Dienstkontos.

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 .gitlab-ci.yml-Datei 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ä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

Die Konfiguration führt Folgendes aus:

1. Weist GitLab an, ein ID-Token auszustellen und in der Umgebungsvariable WORKLOAD_IDENTITY_TOKEN zur Verfügung zu stellen. Das ID-Token verwendet den Anbieter Ihres Workload Identity-Pools als Zielgruppe.
2. Speichert das ID-Token in einer temporären Datei mit dem Namen .workload_identity.jwt.
3. 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.
4. Legt 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 Workload Identity-Föderation verwendet, um sich über die Identitätsübernahme des Dienstkontos bei Google Cloud zu authentifizieren:

1. Öffnen Sie in Terraform Cloud Ihren Arbeitsbereich und rufen Sie Variablen auf.

2. 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 und apply verwendet. Weitere Informationen finden Sie unter Optionale Umgebungsvariablen.

3. 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.

4. 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"
       }
     }
   }
   

5. Senden Sie die Änderungen an Ihr Quellcode-Repository.