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.

    Wählen Sie den Tab für die Verwendung der Beispiele auf dieser Seite aus:

    Console

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

    gcloud

    Sie können die gcloud CLI-Beispiele auf dieser Seite über eine der folgenden Entwicklungsumgebungen verwenden:

    • Cloud Shell: Aktivieren Sie Cloud Shell, um ein Onlineterminal mit der bereits eingerichteten gcloud CLI zu verwenden.

      Unten auf dieser Seite wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Das Initialisieren der Sitzung kann einige Sekunden dauern.

    • Lokale Shell: Zur Verwendung der gcloud CLI in einer lokalen Entwicklungsumgebung müssen Sie die gcloud CLI installieren und initialisieren.

    Python

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

    1. Installieren Sie die Google Cloud CLI.
    2. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

      gcloud init
    3. Erstellen Sie lokale Anmeldedaten zur Authentifizierung für Ihr Google-Konto:

      gcloud auth application-default login

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

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 (api://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.

Workload Identity-Föderation 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. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  2. Es wird empfohlen, ein dediziertes Projekt zum Verwalten von Workload Identity-Pools und -Anbietern zu verwenden.
  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  4. IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs aktivieren.

    Aktivieren Sie die 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:

  • die ARN als Betreff-ID verwenden (Beispiel: "arn:aws:sts::000000000000:assumed-role/ec2-my-role/i-00000000000000000)
  • ein benutzerdefiniertes Attribut account einführen und der AWS-Konto-ID zuweisen
  • ein benutzerdefiniertes Attribut aws_role einführen und ihm den AWS-Rollennamen zuweisen (Beispiel: ec2-my-role)
  • ein benutzerdefiniertes Attribut aws_ec2_instance einführen und der EC2-Instanz-ID zuweisen (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 Textfeld 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"
    

    Dabei gilt:

    • 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"
    

    Dabei gilt:

    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.

Dienstkonto für die externe Arbeitslast erstellen

  1. IAM, Security Token Service, and Service Account Credentials APIs aktivieren.

    Aktivieren Sie die 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.

Externer Arbeitslast erlauben, die Identität des Dienstkontos zu übernehmen

Damit externe Identitäten die Identität eines Dienstkontos übernehmen können, müssen Sie ihnen die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) für das Dienstkonto zuweisen. Sie können die Rolle einer bestimmten externen Identität oder mehreren externen Identitäten zuweisen:

  • Schreiben Sie für eine bestimmte externe Identität eine Attributbedingung, die das Attribut google.subject prüft.
  • Schreiben Sie für eine Gruppe externer Identitäten eine Attributbedingung, die das Attribut google.groups oder ein benutzerdefiniertes Attribut attribute.NAME prüft.

Console

So nutzen Sie die Google Cloud Console, um zuzulassen, dass externe Identitäten die Identität eines Dienstkontos übernehmen:

  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, den Sie aktualisieren möchten, und wählen Sie ihn aus.

  3. Klicken Sie auf Zugriff erlauben, um Zugriff auf den ausgewählten Workload Identity-Pool zu gewähren.

  4. Wählen Sie in der Liste Dienstkonto das Dienstkonto aus, das von den externen Identitäten übernommen werden soll.

  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 Attributzuordnung google.subject=assertion.sub 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 wurden.

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

gcloud

So nutzen Sie die gcloud CLI, um externen Identitäten zu erlauben, die Identität eines Dienstkontos zu übernehmen:

  1. Führen Sie den folgenden Befehl aus, um die Projektnummer Ihres aktuellen Projekts abzurufen:

    gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)
    
  2. So weisen Sie externen Identitäten, die bestimmte Kriterien erfüllen, die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) zu:

    Nach Thema

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
        --role=roles/iam.workloadIdentityUser \
        --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
    

    Nach Gruppe

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
        --role=roles/iam.workloadIdentityUser \
        --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
    

    Nach Attribut

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
        --role=roles/iam.workloadIdentityUser \
        --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
    

    Ersetzen Sie Folgendes:

    • SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos.
    • PROJECT_NUMBER: die Projektnummer des Projekts, das den Workload Identity-Pool enthä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

Anmeldedaten-Konfiguration 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

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, der den IdP enthält, den Sie verwenden möchten, und klicken Sie darauf.

  3. Wählen Sie Verbundene Dienstkonten aus.

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

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

  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

Dabei gilt:

  • 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.
  • SERVICE_ACCOUNT_TOKEN_LIFETIME: Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; der Standardwert ist eine Stunde, wenn nicht angegeben. Wenn Sie eine Lebensdauer von mehr als einer Stunde angeben möchten, müssen Sie die Einschränkung der Organisationsrichtlinien 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

Dabei gilt:

  • PROJECT_NUMBER: 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.
  • APPLICATION_ID_URI: der Anwendungs-ID-URI der Azure-Anwendung
  • SERVICE_ACCOUNT_TOKEN_LIFETIME: Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; der Standardwert ist eine Stunde, wenn nicht angegeben. Wenn Sie eine Lebensdauer von mehr als einer Stunde angeben möchten, müssen Sie die Einschränkung der Organisationsrichtlinien 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 absolute Dateipfad zur Konfigurationsdatei für Anmeldedaten.

    PowerShell

      $env:GOOGLE_APPLICATION_CREDENTIALS = Resolve-Path 'FILEPATH.json'
      
    Dabei ist FILEPATH der absolute Dateipfad 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:. Beispiel:
        //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. Verwenden Sie das Token aus dem Security Token Service, um mit der Methode generateAccessToken der IAM Service Account Credentials API ein Zugriffstoken abzurufen:

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