Workload Identity-Föderation mit AWS oder Azure konfigurieren

In diesem Leitfaden wird beschrieben, wie Sie die Workload Identity-Föderation verwenden, damit sich AWS- und Azure-Arbeitslasten ohne Dienstkontoschlüssel bei Google Cloud authentifizieren können.

Mithilfe der Workload Identity-Föderation können Arbeitslasten, die in AWS EC2 und Azure ausgeführt werden, ihre umgebungsspezifischen Anmeldedaten gegen kurzlebige Google Cloud Security Token Service-Tokens austauschen.

Umgebungsspezifische Anmeldedaten umfassen Folgendes:

Durch das Einrichten der Workload Identity-Föderation können diese Arbeitslasten diese umgebungsspezifischen Anmeldedaten gegen kurzlebige Google Cloud-Anmeldedaten austauschen. Arbeitslasten können mit diesen kurzlebigen Anmeldedaten auf Google Cloud APIs zugreifen.

Hinweise

  • Richten Sie die Authentifizierung ein.

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

    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 dann die Standardanmeldedaten für Anwendungen mit Ihren Nutzeranmeldedaten ein.

    1. Install the Google Cloud CLI.

    2. To initialize the gcloud CLI, run the following command: 

      gcloud init

    3. If you're using a local shell, then create local authentication credentials for your user account: 

      gcloud auth application-default login

      You don't need to do this if you're using Cloud Shell.

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

Externen Identitätsanbieter vorbereiten

Sie müssen diese Schritte nur einmal für jeden Azure AD-Mandanten oder jedes AWS-Konto ausführen.

AWS

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

Nachdem Sie einen Workload Identity-Pool konfiguriert haben, um Ihrem AWS-Konto zu vertrauen, können Sie es AWS-Nutzern und AWS-Rollen erlauben, permanente oder temporäre AWS-Sicherheitsanmeldedaten zu verwenden, um kurzlebige Google Cloud-Anmeldedaten abzurufen.

Azure

Sie müssen eine neue Azure AD-Anwendung in Ihrem Azure AD-Mandanten erstellen und so konfigurieren, dass sie für die Workload Identity-Föderation verwendet werden kann.

Nachdem Sie einen Workload Identity-Pool so konfiguriert haben, dass er der Anwendung vertraut, können Azure-Nutzer und -Diensthauptkonten Zugriffstokens für diese Anwendung anfordern und die Zugriffstokens gegen kurzlebige Google Cloud-Anmeldedaten austauschen.

So erstellen Sie die Anwendung:

  1. Erstellen Sie eine Azure AD-Anwendung und ein Diensthauptkonto.

  2. Legen Sie einen Anwendungs-ID-URI für die Anwendung fest. Sie können den standardmäßigen URI der Anwendung-ID (APPID) verwenden oder einen benutzerdefinierten URI angeben.

    Sie benötigen den Anwendungs-ID-URI später, wenn Sie den Anbieter des Workload Identity-Pools konfigurieren.

Damit eine Anwendung Zugriffstokens für die Azure AD-Anwendung abrufen kann, können Sie verwaltete Identitäten verwenden:

  1. Erstellen Sie eine verwaltete Identität. Notieren Sie sich die Objekt-ID der verwalteten Identität. Sie benötigen sie später, wenn Sie die Identitätsübertragung konfigurieren.

  2. Weisen Sie die verwaltete Identität einer virtuellen Maschine oder einer anderen Ressource zu, auf der Ihre Anwendung ausgeführt wird.

Identitätsföderation von Arbeitslasten konfigurieren

Sie müssen diese Schritte nur einmal pro AWS-Konto oder Azure AD-Mandanten ausführen. Sie können dann denselben Workload Identity-Pool und -Anbieter für mehrere Arbeitslasten und mehrere Google Cloud-Projekte verwenden.

So konfigurieren Sie die Workload Identity-Föderation:

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

    2. Es wird empfohlen, ein dediziertes Projekt zum Verwalten von Workload Identity-Pools und -Anbietern zu verwenden.

  2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

    3. Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

    Enable the APIs

Attributzuordnung und -bedingung definieren

Die umgebungsspezifischen Anmeldedaten Ihrer AWS- oder Azure-Arbeitslast enthalten mehrere Attribute. Sie müssen festlegen, welches Attribut Sie als Subjekt-ID (google.subject) in Google Cloud verwenden möchten.

Google Cloud verwendet die Subjekt-ID in Cloud-Audit-Logs und in Hauptkonto-Kennungen, um AWS- oder Azure-Nutzer bzw. -Rollen eindeutig zu identifizieren.

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.

AWS

Ihre Attributzuordnung kann die Antwortfelder für GetCallerIdentity als Quellattribute verwenden. Zu diesen Feldern gehören:

  • account: die AWS-Kontonummer
  • arn: die AWS-ARN der externen Entität
  • userid: die eindeutige Kennung der aufrufenden Entität

Wenn Ihre Anwendung auf einer EC2-Instanz (Amazon Elastic Compute Cloud) mit einer angehängten Rolle ausgeführt wird, können Sie die folgende Attributzuordnung verwenden:

google.subject=assertion.arn
attribute.account=assertion.account
attribute.aws_role=assertion.arn.extract('assumed-role/{role}/')
attribute.aws_ec2_instance=assertion.arn.extract('assumed-role/{role_and_session}').extract('/{session}')

Die Zuordnung macht Folgendes:

  • Verwendet den ARN als Betreff-ID. Beispiel: "arn:aws:sts::000000000000:assumed-role/ec2-my-role/i-00000000000000000
  • Führt ein benutzerdefiniertes Attribut account ein und weist ihm die AWS-Konto-ID zu
  • Führt ein benutzerdefiniertes Attribut aws_role ein und weist ihm den AWS-Rollennamen zu. Beispiel: ec2-my-role
  • Führt ein benutzerdefiniertes Attribut aws_ec2_instance ein und weist ihm die EC2-Instanz-ID zu. Beispiel: i-00000000000000000

Mit dieser Zuordnung können Sie Zugriff auf Folgendes gewähren:

  • Eine spezifische EC2-Instanz: 

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.aws_ec2_instance/EC2_INSTANCE_ID

  • Alle Nutzer und Instanzen in einer Rolle: 

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.aws_role/ROLE_NAME

Azure

Ihre Attributzuordnungen können die in Azure-Zugriffstokens eingebetteten Anforderungen, einschließlich benutzerdefinierter Anforderungen, als Quellattribute verwenden. In den meisten Fällen empfiehlt es sich, die sub-Anforderung als Subjekt-ID zu verwenden:

google.subject=assertion.sub

Bei einem Zugriffstoken, das für eine verwaltete Identität ausgestellt wurde, enthält die Anforderung sub die Objekt-ID der verwalteten Identität. Wenn Sie eine andere Anforderung verwenden, achten Sie darauf, dass diese Anforderung eindeutig ist und nicht neu zugewiesen werden kann.

Gehen Sie so vor, wenn Sie sich nicht sicher sind, auf welche Liste von Ansprüchen Sie Bezug nehmen können:

  1. Stellen Sie eine Verbindung zu einer Azure-VM her, der eine verwaltete Identität zugewiesen ist.

  2. Rufen Sie ein Zugriffstoken vom Azure Instance Metadata Service (IMDS) ab:

    Bash

    curl \
  "http://169.254.169.254/metadata/identity/oauth2/token?resource=APP_ID_URI&api-version=2018-02-01" \
  -H "Metadata: true" | jq -r .access_token

    Dieser Befehl verwendet das jq-Tool. jq ist standardmäßig in Cloud Shell verfügbar.

    PowerShell

    $SubjectTokenType = "urn:ietf:params:oauth:token-type:jwt"
$SubjectToken = (Invoke-RestMethod `
  -Uri "http://169.254.169.254/metadata/identity/oauth2/token?resource=APP_ID_URI&api-version=2018-02-01" `
  -Headers @{Metadata="true"}).access_token
Write-Host $SubjectToken

    Ersetzen Sie APP_ID_URI durch den Anwendungs-ID-URI der Anwendung, die Sie für die Workload Identity-Föderation konfiguriert haben.

  3. Rufen Sie in einem Webbrowser https://jwt.ms/ auf und fügen Sie das Zugriffstoken in das Feld ein.

  4. Klicken Sie auf Anforderungen, um die Liste der im Zugriffstoken eingebetteten Anforderungen aufzurufen.

Für Dienstidentitäten ist es in der Regel nicht erforderlich, eine Zuordnung für google.groups oder benutzerdefinierte Attribute zu erstellen.

Definieren Sie optional eine Attributbedingung. 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.

AWS

Mit einer Attributbedingung können Sie einschränken, welche IAM-Nutzer und -Rollen die Workload Identity-Föderation verwenden können, um kurzlebige Google Cloud-Tokens abzurufen.

Beispielsweise schränkt die folgende Bedingung den Zugriff auf AWS-Rollen ein und verhindert andere IAM-Kennungen:

assertion.arn.startsWith('arn:aws:sts::AWS_ACCOUNT_ID:assumed-role/')

Azure

Mit einer Attributbedingung können Sie einschränken, welche Nutzer und Diensthauptkonten die Workload Identity-Föderation verwenden können, um kurzlebige Google Cloud-Tokens abzurufen. Alternativ können Sie Ihre Azure AD-Anwendung für die Verwendung von Rollenzuweisungen für Anwendungen konfigurieren.

Workload Identity-Pool und -Anbieter erstellen

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, 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.

Sie haben jetzt alle Informationen zusammen, die Sie zum Erstellen eines Workload Identity-Pools und -Anbieters benötigen:

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 Identitätspool 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:

    AWS

    Konfigurieren Sie die folgenden Anbietereinstellungen:

    • Anbieter auswählen: AWS
    • Name des Anbieters: der Name des Anbieters. Der Name wird auch als Anbieter-ID verwendet. Sie können die Anbieter-ID später nicht mehr ändern.

    Azure

    Konfigurieren Sie die folgenden Anbietereinstellungen:

    • Anbieter auswählen: OpenID Connect (OIDC).
    • Name des Anbieters: Name des Anbieters. Der Name wird auch als Anbieter-ID verwendet. Sie können die Anbieter-ID später nicht mehr ändern.
    • Aussteller-URL: https://sts.windows.net/TENANT_ID. Ersetzen Sie TENANT_ID durch die Mandanten-ID (GUID) Ihres Azure AD-Mandanten.
    • Zulässige Zielgruppen: Anwendungs-ID-URI, den Sie bei der Registrierung der Anwendung in Azure AD verwendet haben.

  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. Lassen Sie das Feld leer, wenn Sie keine Attributbedingung haben.

  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 Folgendes:

    • 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-Pool-Anbieter hinzu:

    AWS

    Führen Sie den folgenden Befehl aus, um den Workload Identity-Poolanbieter für AWS zu erstellen:

    gcloud iam workload-identity-pools providers create-aws PROVIDER_ID \
  --location="global" \
  --workload-identity-pool="POOL_ID" \
  --account-id="ACCOUNT_ID" \
  --attribute-mapping="MAPPINGS" \
  --attribute-condition="CONDITIONS"

    Ersetzen Sie Folgendes:

    Beispiel:

    gcloud iam workload-identity-pools providers create-aws example-provider \
  --location="global" \
  --workload-identity-pool="pool-1" \
  --account-id="123456789000" \
  --attribute-mapping="google.subject=assertion.arn"

    Azure

    Führen Sie den folgenden Befehl aus, um den Workload Identity-Poolanbieter für Azure zu erstellen:

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER_URI" \
    --allowed-audiences="APPLICATION_ID_URI" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"

    Ersetzen Sie Folgendes:

    • PROVIDER_ID: Die eindeutige ID des Anbieters.
    • POOL_ID: Die ID des Pools.
    • ISSUER_URI: Die Mandanten-ID (GUID) Ihres Azure AD-Mandanten, die manchmal als https://sts.windows.net/TENANT_ID formatiert ist. Der Aussteller-URI kann variieren und um den Aussteller-URI zu ermitteln, können Sie das JWT mit JWT.io debuggen.
    • APPLICATION_ID_URI: Anwendungs-ID-URI, den Sie bei der Registrierung der Anwendung in Azure AD verwendet haben.
    • MAPPINGS: Die durch Kommas getrennte Liste der Attributzuordnungen, die Sie zuvor identifiziert haben.
    • CONDITIONS: (Optional) Die Attributbedingung, die Sie zuvor identifiziert haben.

    Beispiel:

    gcloud iam workload-identity-pools providers create-oidc example-provider \
    --location="global" \
    --workload-identity-pool="pool-1" \
    --issuer-uri="https://sts.windows.net/00000000-1111-2222-3333-444444444444" \
    --allowed-audiences="api://my-app" \
    --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups"

Arbeitslast authentifizieren

Sie müssen diese Schritte einmal pro Arbeitslast ausführen.

Externer Arbeitslast den Zugriff auf Google Cloud-Ressourcen erlauben

Damit Ihre Arbeitslast Zugriff auf Google Cloud-Ressourcen erhält, sollten Sie dem Hauptkonto direkten Ressourcenzugriff gewähren. In diesem Fall ist das Hauptkonto der föderierte Nutzer. Einige Google Cloud-Produkte unterliegen Google Cloud API-Einschränkungen. Wenn Ihre Arbeitslast einen API-Endpunkt mit einer Einschränkung aufruft, können Sie stattdessen die Identitätsübernahme des Dienstkontos verwenden. In diesem Fall ist das Hauptkonto das Google 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 über die Google Cloud Console oder die gcloud CLI gewähren.

Console

Wenn Sie die Google Cloud Console verwenden möchten, um IAM-Rollen direkt für eine Ressource zuzuweisen, müssen Sie die Seite der Ressource aufrufen und dann die Rolle zuweisen. Das folgende Beispiel zeigt, wie Sie die Cloud Storage-Seite aufrufen und einer föderierten Identität die Rolle "Storage-Objekt-Betrachter" (roles/storage.objectViewer) direkt in einem Cloud Storage-Bucket zuweisen.

  1. Wechseln Sie in der Cloud Console zur Seite Cloud Storage-Buckets.

    Buckets aufrufen

  2. Klicken Sie in der Liste der Buckets auf den Namen des Buckets, für den Sie die Rolle zuweisen möchten.

  3. Wählen Sie oben auf der Seite den Tab Berechtigungen aus.

  4. Klicken Sie auf die Schaltfläche Zugriff gewähren.

    Das Dialogfeld Hauptkonten hinzufügen wird angezeigt.

  5. Geben Sie in das Feld Neue Hauptkonten eine oder mehrere Identitäten ein, die Zugriff auf den Bucket erhalten sollen.

    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 von Ihrem IdP zugeordnete Gruppe, 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

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

  7. Klicken Sie auf Speichern.

gcloud

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

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

  2. 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 „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) 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.

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

Konfiguration von Anmeldedaten herunterladen oder erstellen

Die Cloud-Clientbibliotheken, die gcloud CLI und Terraform können automatisch externe Anmeldedaten abrufen und mit diesen die Identität eines Dienstkontos übernehmen. Damit Bibliotheken und Tools diesen Vorgang abschließen können, müssen Sie eine Konfigurationsdatei für Anmeldedaten angeben. Die Datei definiert Folgendes:

  • Wo externe Anmeldedaten abgerufen werden
  • Welcher Workload Identity-Pool und -Anbieter verwendet werden
  • Welches Dienstkonto übernommen wird

So erstellen Sie eine Konfigurationsdatei für Anmeldedaten:

Console

So laden Sie eine Konfigurationsdatei für Anmeldedaten in der Google Cloud Console herunter:

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

    Zu Workload Identity-Pools

  2. Suchen Sie den Workload Identity-Pool für den IdP, den Sie verwenden möchten, und klicken Sie darauf.

  3. Wenn Sie den direkten Ressourcenzugriff verwenden, gehen Sie so vor:

    1. Klicken Sie auf Zugriff erlauben.

    2. Wählen Sie Zugriff mit föderierten Identitäten gewähren (empfohlen) aus.

    3. Klicken Sie auf Herunterladen.

    4. Fahren Sie mit der Anleitung im Dialogfeld Anwendung konfigurieren weiter unten in diesem Verfahren fort.

  4. Wenn Sie die Identitätsübernahme des Dienstkontos verwenden möchten, gehen Sie so vor:

    1. Wählen Sie Verbundene Dienstkonten aus.

    2. Suchen Sie das Dienstkonto, das Sie verwenden möchten, und klicken Sie auf Herunterladen.

    3. Fahren Sie mit der Anleitung im Dialogfeld Anwendung konfigurieren weiter unten in diesem Verfahren fort.

  5. Wählen Sie im Dialogfeld Anwendung konfigurieren den Anbieter aus, der die externen Identitäten enthält.

  6. Nehmen Sie die folgenden zusätzlichen Einstellungen vor:

    AWS

    Es sind keine zusätzlichen Einstellungen erforderlich.

    Azure

    Anwendungs-ID-URL: Anwendungs-ID-URI der Azure-Anwendung

  7. Wählen Sie Konfiguration herunterladen aus, um die Konfigurationsdatei für Anmeldedaten herunterzuladen, und klicken Sie dann auf Schließen.

gcloud

So erstellen Sie eine Konfigurationsdatei für Anmeldedaten mit gcloud iam workload-identity-pools create-cred-config:

AWS

So erstellen Sie eine Konfigurationsdatei für Anmeldedaten, mit der die Bibliothek ein Zugriffstoken aus EC2-Instanzmetadaten abrufen kann:

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --aws \
    --output-file=FILEPATH.json

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 Anbieters des Workload Identity-Pools.
  • SERVICE_ACCOUNT_EMAIL: Wenn Sie die Identitätsübernahme des Dienstkontos verwenden, ersetzen Sie dies durch die E-Mail-Adresse des Dienstkontos. Lassen Sie dieses Flag weg, wenn Sie keine Identitätsübernahme des Dienstkontos verwenden.
  • SERVICE_ACCOUNT_TOKEN_LIFETIME: Wenn Sie die Identitätsübernahme für ein Dienstkonto verwenden, ersetzen Sie dies durch die Lebensdauer des Zugriffstokens für das Dienstkonto in Sekunden. Der Standardwert ist eine Stunde, wenn nicht angegeben. Lassen Sie dieses Flag weg, wenn Sie keine Identitätsübernahme des Dienstkontos verwenden. Wenn Sie eine Lebensdauer angeben möchten, die länger als eine Stunde ist, müssen Sie die Einschränkung der Organisationsrichtlinie constraints/iam.allowServiceAccountCredentialLifetimeExtension konfigurieren.
  • FILEPATH: die Datei, in der die Konfiguration gespeichert werden soll

Wenn Sie AWS IMDSv2 verwenden, muss dem Befehl gcloud iam workload-identity-pools create-cred-config ein zusätzliches Flag --enable-imdsv2 hinzugefügt werden:

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --aws \
    --enable-imdsv2 \
    --output-file=FILEPATH.json

Ist die Verwendung des AWS-Metadatenservers nicht möglich, können Sie AWS-Sicherheitsanmeldedaten über folgende AWS-Umgebungsvariablen angeben:

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • Entweder AWS_REGION oder AWS_DEFAULT_REGION
  • Optional: AWS_SESSION_TOKEN

Die gcloud CLI und die Bibliotheken verwenden diese AWS-Umgebungsvariablen, wenn der AWS-Metadatenserver nicht verfügbar ist.

Azure

Erstellen Sie eine Konfigurationsdatei für Anmeldedaten, mit der die Bibliothek ein Zugriffstoken vom Azure Instance Metadata Service (IMDS) abrufen kann:

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --azure \
    --app-id-uri APPLICATION_ID_URI \
    --output-file=FILEPATH.json

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 Anbieters des Workload Identity-Pools.
  • SERVICE_ACCOUNT_EMAIL: Wenn Sie die Identitätsübernahme des Dienstkontos verwenden, ersetzen Sie dies durch die E-Mail-Adresse des Dienstkontos. Lassen Sie dieses Flag weg, wenn Sie keine Identitätsübernahme des Dienstkontos verwenden.
  • APPLICATION_ID_URI: der Anwendungs-ID-URI der Azure-Anwendung
  • SERVICE_ACCOUNT_TOKEN_LIFETIME: Wenn Sie die Identitätsübernahme des Dienstkontos verwenden, Lebensdauer des Zugriffstokens für das Dienstkonto in Sekunden, ist der Standardwert eine Stunde, wenn nicht angegeben. Lassen Sie dieses Flag weg, wenn Sie keine Identitätsübernahme des Dienstkontos verwenden. Wenn Sie eine Lebensdauer angeben möchten, die länger als eine Stunde ist, müssen Sie die Einschränkung der Organisationsrichtlinie constraints/iam.allowServiceAccountCredentialLifetimeExtension konfigurieren.
  • FILEPATH: die Datei, in der die Konfiguration gespeichert werden soll

Anmeldedatenkonfiguration für den Zugriff auf Google Cloud verwenden

Führen Sie die folgenden Schritte in Ihrer AWS- oder Azure-Umgebung aus, damit Tools und Clientbibliotheken Ihre Anmeldedatenkonfiguration verwenden können:

  1. Initialisieren Sie eine Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS und verweisen Sie auf die Konfigurationsdatei für Anmeldedaten:

    Bash

      export GOOGLE_APPLICATION_CREDENTIALS=`pwd`/FILEPATH.json
    Dabei ist FILEPATH der relative Pfad zur Konfigurationsdatei für Anmeldedaten.

    PowerShell

      $env:GOOGLE_APPLICATION_CREDENTIALS = Resolve-Path 'FILEPATH.json'
    Dabei ist FILEPATH der relative Pfad zur Konfigurationsdatei für Anmeldedaten.

  2. Verwenden Sie eine Clientbibliothek oder ein Tool, das die Workload Identity-Föderation unterstützt und Anmeldedaten automatisch finden kann:

    C++

    Die Google Cloud-Clientbibliotheken für C++ unterstützen die Mitarbeiteridentitätsföderation seit Version v2.6.0. Wenn Sie die Mitarbeiteridentitätsföderation verwenden möchten, müssen Sie die Clientbibliotheken mit Version 1.36.0 oder höher von gRPC erstellen.

    Einfach loslegen (Go)

    Clientbibliotheken für Go unterstützen die Identitätsföderation, wenn sie Version 0.0.0-2021218202405-ba52d332ba99 oder höher des Moduls golang.org/x/oauth2 verwenden.

    Führen Sie die folgenden Befehle aus, um zu überprüfen, welche Version dieses Moduls in Ihrer Clientbibliothek verwendet wird:

    cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2

    Java

    Clientbibliotheken für Java unterstützen die Identitätsföderation, wenn sie Version 0.24.0 oder höher des com.google.auth:google-auth-library-oauth2-http-Artefakts verwenden.

    Führen Sie den folgenden Maven-Befehl in Ihrem Anwendungsverzeichnis aus, um zu überprüfen, welche Version dieses Artefakts Ihre Clientbibliothek verwendet:

    mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http

    Node.js

    Clientbibliotheken für Node.js unterstützen die Workload Identity-Föderation, wenn sie Version 7.0.2 oder höher des google-auth-library-Pakets verwenden.

    Führen Sie den folgenden Befehl in Ihrem Anwendungsverzeichnis aus, um zu überprüfen, welche Version dieses Pakets verwendet wird:

    npm list google-auth-library

    Wenn Sie ein GoogleAuth-Objekt erstellen, können Sie eine Projekt-ID angeben oder GoogleAuth erlauben, automatisch nach der Projekt-ID zu suchen. Damit automatisch nach der Projekt-ID gesucht werden kann, muss das Dienstkonto in der Konfigurationsdatei in Ihrem Projekt die Rolle „Sucher“ (roles/browser) oder eine Rolle mit entsprechenden Berechtigungen haben. Weitere Informationen finden Sie unter README für das Paket google-auth-library.

    Python

    Clientbibliotheken für Python unterstützen die Identitätsföderation, wenn sie Version 1.7.0 oder höher des google-auth-Pakets verwenden.

    Führen Sie den folgenden Befehl in der Umgebung aus, in der das Paket installiert ist, um zu ermitteln, welche Version dieses Pakets verwendet wird:

    pip show google-auth

    Wenn Sie eine Projekt-ID für den Authentifizierungsclient angeben, können Sie die Umgebungsvariable GOOGLE_CLOUD_PROJECT festlegen oder Sie gestatten dem Client, automatisch nach der Projekt-ID zu suchen. Damit automatisch nach der Projekt-ID gesucht werden kann, muss das Dienstkonto in der Konfigurationsdatei in Ihrem Projekt die Rolle „Sucher“ (roles/browser) oder eine Rolle mit entsprechenden Berechtigungen haben. Weitere Informationen finden Sie im Nutzerhandbuch für das Paket google-auth.

    gcloud

    Verwenden Sie zum Authentifizieren der Workload Identity-Föderation den Befehl gcloud auth login:

    gcloud auth login --cred-file=FILEPATH.json

    Ersetzen Sie FILEPATH durch den Dateipfad zur Konfigurationsdatei für Anmeldedaten.

    Unterstützung für die Workload Identity-Föderation in der gcloud CLI ist in Version 363.0.0 und höher des gcloud CLI verfügbar.

    Terraform

    Der Google Cloud-Anbieter unterstützt die Workload Identity-Föderation, wenn Sie Version 3.61.0 oder höher verwenden:

    terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 3.61.0"
    }
  }
}

    gsutil

    Verwenden Sie eine der folgenden Methoden, um sich mit einer Workload Identity-Föderation zu authentifizieren:

    Wenn Sie gsutil zusammen mit gcloud verwenden, melden Sie sich wie gewohnt an:

    gcloud auth login --cred-file=FILEPATH.json

    Wenn Sie gsutil als eigenständige Befehlszeilenanwendung verwenden, bearbeiten Sie die .boto-Datei so, dass sie Folgendes enthält:

    [Credentials]
gs_external_account_file = FILEPATH

    Ersetzen Sie in beiden Fällen FILEPATH durch den Dateipfad zur Konfigurationsdatei für Anmeldedaten.

    Unterstützung für Workload Identity-Föderation in gsutil ist in Version 379.0.0 und späteren Versionen der gcloud CLI verfügbar.

    bq

    Verwenden Sie für die Authentifizierung mithilfe der Workload Identity-Föderation den Befehl gcloud auth login:

    gcloud auth login --cred-file=FILEPATH.json

    Ersetzen Sie FILEPATH durch den Dateipfad zur Konfigurationsdatei für Anmeldedaten.

    Unterstützung für Workload Identity-Föderation in bq ist in Version 390.0.0 und späteren Versionen der gcloud CLI verfügbar.

    Wenn Sie keine Clientbibliothek verwenden können, die Workload Identity-Föderation unterstützt, können Sie sich mit der REST API programmatisch authentifizieren.

Erweiterte Szenarien

Arbeitslast mit der REST API authentifizieren

Wenn Sie keine Clientbibliotheken verwenden können, führen Sie die folgenden Schritte aus, damit eine externe Identität ein kurzlebiges Zugriffstoken mithilfe der REST API abrufen kann:

  1. Rufen Sie Anmeldedaten von Ihrem externen IdP ab:

    AWS

    Erstellen Sie ein JSON-Dokument mit den Informationen, die Sie normalerweise in eine Anfrage an den AWS-Endpunkt GetCallerIdentity() aufnehmen würden, einschließlich einer gültigen Anfragesignatur.

    Workload Identity-Föderation bezeichnet dieses JSON-Dokument als GetCallerIdentity-Token. Mit dem Token kann die Workload Identity-Föderation die Identität prüfen, ohne den geheimen AWS-Zugriffsschlüssel preiszugeben.

    Ein GetCallerIdentity-Token sieht in etwa so aus:

    {
  "url": "https://sts.amazonaws.com?Action=GetCallerIdentity&Version=2011-06-15",
  "method": "POST",
  "headers": [
    {
      "key": "Authorization",
      "value" : "AWS4-HMAC-SHA256 Credential=AKIASOZTBDV4D7ABCDEDF/20200228/us-east-1/sts/aws4_request, SignedHeaders=host;x-amz-date,Signature=abcedefdfedfd"
    },
    {
      "key": "host",
      "value": "sts.amazonaws.com"
    },
    {
      "key": "x-amz-date",
      "value": "20200228T225005Z"
    },
    {
      "key": "x-goog-cloud-target-resource",
      "value": "//iam.googleapis.com/projects/12345678/locations/global/workloadIdentityPools/my-pool/providers/my-aws-provider"
    },
    {
      "key": "x-amz-security-token",
      "value": "GizFWJTqYX...xJ55YoJ8E9HNU="
    }
  ]
}

    Das Token enthält die folgenden Felder:

    • url: die URL des AWS STS-Endpunkts für GetCallerIdentity(), wobei der Text einer Standardanfrage GetCallerIdentity() als Abfrageparameter angehängt wird. Beispiel: https://sts.amazonaws.com?Action=GetCallerIdentity&Version=2011-06-15. Wir empfehlen die Verwendung regionaler STS-Endpunkte und das Entwerfen einer zuverlässigen Infrastruktur für Ihre Arbeitslasten. Weitere Informationen finden Sie unter Regionale AWS STS-Endpunkte.
    • method: Die HTTP-Anfragemethode POST.
    • headers: Die HTTP-Anfrageheader, die Folgendes enthalten müssen:
      • Authorization: Die Anfragesignatur.
      • host: Den Hostnamen des Felds url, z. B. sts.amazonaws.com.
      • x-amz-date: Den Zeitpunkt, an dem Sie die Anfrage senden möchten, angegeben im Stringformat ISO 8601 Basic. In der Regel wird dieser Wert auf die aktuelle Zeit festgelegt und zur Vermeidung von Replay-Angriffen verwendet.
      • x-goog-cloud-target-resource: der vollständige Ressourcennamen des Identitätsanbieters ohne das Präfix https:. Beispiele: 
        //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
      • x-amz-security-token: Sitzungstoken. Nur erforderlich, wenn Sie temporäre Sicherheitsanmeldedaten verwenden.

    Im folgenden Beispiel wird ein URL-codiertes GetCallerIdentity-Token erstellt. Extrahieren Sie das URL-codierte Token zur späteren Verwendung. Außerdem wird ein für Menschen lesbares Token zur Referenz erstellt:

    import json
import urllib

import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest

def create_token_aws(project_number: str, pool_id: str, provider_id: str) -> None:
    # Prepare a GetCallerIdentity request.
    request = AWSRequest(
        method="POST",
        url="https://sts.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15",
        headers={
            "Host": "sts.amazonaws.com",
            "x-goog-cloud-target-resource": f"//iam.googleapis.com/projects/{project_number}/locations/global/workloadIdentityPools/{pool_id}/providers/{provider_id}",
        },
    )

    # Set the session credentials and Sign the request.
    # get_credentials loads the required credentials as environment variables.
    # Refer:
    # https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html
    SigV4Auth(boto3.Session().get_credentials(), "sts", "us-east-1").add_auth(request)

    # Create token from signed request.
    token = {"url": request.url, "method": request.method, "headers": []}
    for key, value in request.headers.items():
        token["headers"].append({"key": key, "value": value})

    # The token lets workload identity federation verify the identity without revealing the AWS secret access key.
    print("Token:\n%s" % json.dumps(token, indent=2, sort_keys=True))
    print("URL encoded token:\n%s" % urllib.parse.quote(json.dumps(token)))

def main() -> None:
    # TODO(Developer): Replace the below credentials.
    # project_number: Google Project number (not the project id)
    project_number = "my-project-number"
    pool_id = "my-pool-id"
    provider_id = "my-provider-id"

    create_token_aws(project_number, pool_id, provider_id)

if __name__ == "__main__":
    main()

    Initialisieren Sie die folgenden Variablen:

    Bash

    SUBJECT_TOKEN_TYPE="urn:ietf:params:aws:token-type:aws4_request"
SUBJECT_TOKEN=TOKEN

    PowerShell

    $SubjectTokenType = "urn:ietf:params:aws:token-type:aws4_request"
$SubjectToken = "TOKEN"

    Dabei ist TOKEN das URL-codierte GetCallerIdentity-Token, das vom obigen Skript generiert wurde.

    Azure

    Stellen Sie eine Verbindung zu einer Azure-VM her, der eine verwaltete Identität zugewiesen ist, und rufen Sie ein Zugriffstoken vom Azure Instance Metadata Service (IMDS) ab:

    Bash

    SUBJECT_TOKEN_TYPE="urn:ietf:params:oauth:token-type:jwt"
SUBJECT_TOKEN=$(curl \
  "http://169.254.169.254/metadata/identity/oauth2/token?resource=APP_ID_URI&api-version=2018-02-01" \
  -H "Metadata: true" | jq -r .access_token)
echo $SUBJECT_TOKEN

    Dieser Befehl verwendet das jq-Tool. jq ist standardmäßig in Cloud Shell verfügbar.

    PowerShell

    $SubjectTokenType = "urn:ietf:params:oauth:token-type:jwt"
$SubjectToken = (Invoke-RestMethod `
  -Uri "http://169.254.169.254/metadata/identity/oauth2/token?resource=APP_ID_URI&api-version=2018-02-01" `
  -Headers @{Metadata="true"}).access_token
Write-Host $SubjectToken

    Dabei ist APP_ID_URI der Anwendungs-ID-URI der Anwendung, die Sie für die Workload Identity-Föderation konfiguriert haben.

  2. Verwenden Sie die Security Token Service API, um die Anmeldedaten gegen ein kurzlebiges Zugriffstoken auszutauschen:

    Bash

    STS_TOKEN=$(curl https://sts.googleapis.com/v1/token \
    --data-urlencode "audience=//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID" \
    --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
    --data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:access_token" \
    --data-urlencode "scope=https://www.googleapis.com/auth/cloud-platform" \
    --data-urlencode "subject_token_type=$SUBJECT_TOKEN_TYPE" \
    --data-urlencode "subject_token=$SUBJECT_TOKEN" | jq -r .access_token)
echo $STS_TOKEN

    PowerShell

    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12
$StsToken = (Invoke-RestMethod `
    -Method POST `
    -Uri "https://sts.googleapis.com/v1/token" `
    -ContentType "application/json" `
    -Body (@{
        "audience"           = "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID"
        "grantType"          = "urn:ietf:params:oauth:grant-type:token-exchange"
        "requestedTokenType" = "urn:ietf:params:oauth:token-type:access_token"
        "scope"              = "https://www.googleapis.com/auth/cloud-platform"
        "subjectTokenType"   = $SubjectTokenType
        "subjectToken"       = $SubjectToken
    } | ConvertTo-Json)).access_token
Write-Host $StsToken

    Ersetzen Sie die folgenden Werte:

    • PROJECT_NUMBER: Die Projektnummer des Projekts, das den Workload Identity-Pool enthält
    • POOL_ID: ID des Workload Identity-Pools
    • PROVIDER_ID: ID des Workload Identity-Pool-Anbieters

  3. Wenn Sie die Identitätsübernahme des Dienstkontos verwenden, verwenden Sie das Token aus dem Security Token Service, um die Methode generateAccessToken der IAM Service Account Credentials API aufzurufen. So erhalten Sie ein Zugriffstoken:

Bash

ACCESS_TOKEN=$(curl -0 -X POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT_EMAIL:generateAccessToken \
    -H "Content-Type: text/json; charset=utf-8" \
    -H "Authorization: Bearer $STS_TOKEN" \
    -d @- <<EOF | jq -r .accessToken
    {
        "scope": [ "https://www.googleapis.com/auth/cloud-platform" ]
    }
EOF
)
echo $ACCESS_TOKEN

PowerShell

$AccessToken = (Invoke-RestMethod `
    -Method POST `
    -Uri "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT_EMAIL:generateAccessToken" `
    -Headers @{ "Authorization" = "Bearer $StsToken" } `
    -ContentType "application/json" `
    -Body (@{
        "scope" = , "https://www.googleapis.com/auth/cloud-platform"
    } | ConvertTo-Json)).accessToken
Write-Host $AccessToken

Ersetzen Sie SERVICE_ACCOUNT_EMAIL durch die E-Mail-Adresse des Dienstkontos.

Nächste Schritte