Kurzlebige Anmeldedaten mit der Identity-Föderation abrufen

In diesem Leitfaden wird beschrieben, wie Sie mit einem Workload Identity-Pool und -Anbieter kurzlebige Anmeldedaten abrufen. Dazu gehen Sie so vor:

  1. Rufen Sie Anmeldedaten vom vertrauenswürdigen Identitätsanbieter ab.
  2. Tauschen Sie die Anmeldedaten gegen ein Token des Security Token Service aus.
  3. Verwenden Sie das Token des Security Token Service, um eine Identität als Dienstkonto zu übernehmen und ein kurzlebiges Google-Zugriffstoken abzurufen.

Mit den kurzlebigen Google-Zugriffstokens können Sie auf alle Google Cloud-Ressourcen zugreifen, auf die das Dienstkonto Zugriff hat.

Hinweis

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

    Aktivieren Sie die APIs

  2. Erstellen Sie eine Föderation mit einem externen Identitätsanbieter, indem Sie einen Workload Identity-Pool und -Anbieter erstellen.

  3. Erstellen Sie ein Dienstkonto, das externe Identitäten übernehmen sollen.

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

Externen Identitäten die Berechtigung erteilen, die Identität eines 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.
  • Verwenden Sie für keine der externen Identitäten im Workload Identity-Pool eine Attributbedingung.

Console

  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 klicken Sie darauf.

  3. Klicken Sie auf Zugriff erlauben.

  4. Wählen Sie in der Drop-down-Liste Dienstkonto das Dienstkonto aus, das die externen Identitäten imitieren soll.

  5. Wählen Sie aus, 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 Drop-down-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 Attributzuordnung google.subject=assertion.sub verwenden, legen Sie den Attribut-Namen auf subject und den Attributwert auf den Wert der sub-Anforderung in Tokens fest, die von Ihrem externen Identitätsanbieter ausgestellt wurden.

    • Damit alle externen Identitäten des Workload Identity-Pools die Identität des Dienstkontos übernehmen können, wählen Sie Alle Identitäten im Pool aus.

  6. Klicken Sie auf Speichern.

  7. Klicken Sie auf Ablehnen.

gcloud

  1. Erstellen Sie eine Kennung für die externen Identitäten:

    • Eine bestimmte externe Identität:

      principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT

    • Eine Gruppe externer Identitäten:

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP

    • Alle externen Identitäten mit einem bestimmten Attribut:

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE

    • Alle externen Identitäten in einem Workload Identity-Pool:

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*

    Ersetzen Sie die folgenden Werte:

    • PROJECT_NUMBER: Projektnummer des Projekts, das den Workload Identity-Pool enthält
    • POOL_ID: Pool-ID des Workload Identity-Pools
    • SUBJECT: erwarteter Wert für das Attribut, das Sie google.subject zugeordnet haben
    • GROUP: erwarteter Wert für das Attribut, das Sie google.groups zugeordnet haben
    • ATTRIBUTE_NAME: Name eines benutzerdefinierten Attributs in Ihrer Attributzuordnung

    Die Projektnummer Ihres aktuellen Projekts können Sie mit dem folgenden Befehl abrufen:

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

  2. Weisen Sie dem Hauptkonto des Dienstkontos die Rolle "Workload Identity-Nutzer" (roles/iam.workloadIdentityUser) zu:

    gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="MEMBER_ID"

    Ersetzen Sie die folgenden Werte:

    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • MEMBER_ID: Mitglieds-ID, die Sie im vorherigen Schritt identifiziert haben

Authentifizierung mit Clientbibliotheken, dem gcloud CLI oder Terraform durchführen

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

Wie die Konfigurationsdateien der Anmeldedaten von den Clientbibliotheken verwendet werden, hängt von Ihrem externen Identitätsanbieter ab:

AWS

Die Clientbibliotheken erhalten automatisch temporäre Anmeldedaten aus den EC2-Instanz-Metadaten.

Azure

Die Clientbibliotheken erhalten automatisch Zugriffstokens vom Azure Instance Metadata Service (IMDS).

GitHub Actions

Da die Parameter, die zum Abrufen eines GitHub-ID-Tokens erforderlich sind, bei jeder Workflowausführung variieren, können Sie in einem GitHub Actions-Workflow keine statische Anmeldedatenkonfigurationsdatei verwenden.

Verwenden Sie die Aktion google-github-actions/auth, um während der Workflowausführung automatisch eine Konfigurationsdatei für Anmeldedaten zu generieren. Clientbibliotheken und Tools wie terraform können diese Konfigurationsdatei für Anmeldedaten dann verwenden, um Google-Anmeldedaten automatisch zu erhalten.

OIDC

Die Clientbibliotheken erhalten Anmeldedaten aus einer lokalen Datei, einer HTTP-URL oder einer lokalen ausführbaren Datei:

  • Dateibasierte Anmeldedaten: Tokens werden aus einer Datei geladen. Ein anderer Prozess muss diese Datei mit einem neuen OIDC-Token aktualisieren, bevor das alte Token abläuft. Wenn das Token beispielsweise eine Lebensdauer von 1 Stunde hat, müssen Sie die Datei vor einer Stunde aktualisieren.
  • URL-basierte Anmeldedaten: Tokens werden von einem lokalen Server mit einem Endpunkt geladen, der auf HTTP-GET-Anfragen antwortet. Die Antwort muss ein OIDC-ID-Token sein, entweder im Nur-Text- oder JSON-Format.

  • Ausführbare Anmeldedaten: Tokens werden aus einer lokalen ausführbaren Datei geladen. Die ausführbare Datei muss ein gültiges, nicht abgelaufenes OIDC-ID-Token im JSON-Format für stdout bereitstellen: 

    {
  "version": 1,
  "success": true,
  "token_type": "urn:ietf:params:oauth:token-type:id_token",
  "id_token": "HEADER.PAYLOAD.SIGNATURE",
  "expiration_time": 1620499962
}
    Diese Felder sind mit Ausnahme von expiration_time für eine erfolgreiche Antwort erforderlich. Das Feld expiration_time ist nur erforderlich, wenn in der Konfiguration der Anmeldedaten eine Ausgabedatei angegeben wurde.

    Wenn ein Fehler auftritt, muss dieser von der ausführbaren Datei im folgenden JSON-Format für stdout angezeigt werden: 

    {
  "version": 1,
  "success": false,
  "code": "401",
  "message": "Caller not authorized."
}
    Alle diese Felder sind für eine Fehlerantwort erforderlich. Die Code- und Nachrichtenfelder werden von den Clientbibliotheken verwendet, wenn der entsprechende Fehler ausgegeben wird.

    Zusammenfassung der Antwortformatfelder:

    • version: Die Version der JSON-Ausgabe. Derzeit wird nur Version 1 unterstützt.
    • success: Der Status der Antwort. Bei „true“ muss die Antwort das Token des Drittanbieters, den Tokentyp und das Ablaufdatum enthalten. Die ausführbare Datei muss auch mit dem Exit-Code 0 beendet werden. Bei „false“ muss die Antwort den Fehlercode und die Nachrichtenfelder enthalten und mit einem Wert ungleich Null beendet werden.
    • token_type: der Tokentyp des Drittanbieter-Subjekts. Unterstützte Werte sind urn:ietf:params:oauth:token-type:id_token und urn:ietf:params:oauth:token-type:jwt.
    • id_token: das OIDC-Token des Drittanbieters.
    • expiration_time: die Ablaufzeit des OIDC-Tokens in Sekunden (Unixzeit).
    • code: Der Fehlercodestring.
    • message: Die Fehlermeldung

    Die Clientbibliotheken füllen die folgenden Umgebungsvariablen aus, wenn die ausführbare Datei ausgeführt wird:

    • GOOGLE_EXTERNAL_ACCOUNT_AUDIENCE: Das Feld für die Zielgruppe aus der Konfiguration der Anmeldedaten. Immer vorhanden.
    • GOOGLE_EXTERNAL_ACCOUNT_TOKEN_TYPE: Der erwartete Tokentyp des Subjekts. Immer vorhanden.
    • GOOGLE_EXTERNAL_ACCOUNT_IMPERSONATED_EMAIL: die E-Mail-Adresse des Dienstkontos. Nur vorhanden, wenn die Identitätsübernahme des Dienstkontos verwendet wird.
    • GOOGLE_EXTERNAL_ACCOUNT_OUTPUT_FILE: Der Speicherort der Ausgabedatei aus der Konfiguration von Anmeldedaten. Nur vorhanden, wenn in der Konfiguration der Anmeldedaten angegeben.

    Diese Umgebungsvariablen können von der ausführbaren Datei verwendet werden, um eine Hartcodierung dieser Werte zu vermeiden.

    Um diese Methode der Anmeldedatenbereitstellung für die Clientbibliotheken zu aktivieren, muss die Umgebungsvariable GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES auf 1 festgelegt sein.

OIDC (AD FS)

Die Clientbibliotheken können Anmeldedaten von einer lokalen Datei oder einer HTTP-URL abrufen, unterstützen aber nicht die integrierte Windows-Authentifizierung (IWA). Verwenden Sie den folgenden PowerShell-Befehl, um ein Zugriffstoken für den angemeldeten Nutzer abzurufen und in einer lokalen Datei zu speichern:

(Invoke-RestMethod `
    -Uri "https://ADFS_DOMAIN/adfs/oauth2/token/" `
    -Method POST `
    -Body @{
        client_id = 'CLIENT_ID'
        grant_type = 'client_credentials'
        scope = 'openid'
        resource = 'RELYING_PARTY_ID'
        use_windows_client_authentication = 'true'
        } `
    -UseDefaultCredentials).access_token | Out-File -Encoding ASCII TOKEN_FILEPATH

Ersetzen Sie die folgenden Werte:

  • ADFS_DOMAIN: öffentlicher Domainname des AD FS-Servers der Farm.
  • CLIENT_ID: Client-ID der Anwendungsregistrierung in AD FS.
  • RELYING_PARTY_ID: Kennung der vertrauenswürdigen Partei, die Sie beim Erstellen einer Web API-Anwendung für den Workload Identity-Pool in AD FS verwendet haben.
  • TOKEN_FILEPATH: Pfad zu einer temporären Datei, in der das AD FS-Token gespeichert werden soll. Speichern Sie die Datei an einem Ort, an dem nur autorisierte Nutzer den Inhalt der Datei lesen können.

Da die kurzlebigen Google-Anmeldedaten nur für einen begrenzten Zeitraum (standardmäßig eine Stunde) gültig sind, müssen Sie diesen Befehl regelmäßig noch einmal ausführen.

SAML

Die Clientbibliotheken erhalten Anmeldedaten aus einer lokalen Datei, einer HTTP-URL oder einer lokalen ausführbaren Datei:

  • Dateibasierte Anmeldedaten: Assertionen werden aus einer Datei geladen. Vor dem Ablauf der alten Assertion muss diese Datei von einem anderen Prozess mit einer neuen base64-codierten SAML-Assertion aktualisiert werden. Wenn die Assertion beispielsweise eine Lebensdauer von 1 Stunde hat, müssen Sie die Datei innerhalb einer Stunde aktualisieren.
  • URL-basierte Anmeldedaten: Assertions werden von einem lokalen Server mit einem Endpunkt geladen, der auf HTTP-GET-Anfragen antwortet. Die Antwort muss entweder eine base64-codierte SAML-Assertion oder eine JSON-Datei sein, die eine base64-codierte SAML-Assertion enthält.

  • Ausführbare Anmeldedaten: Assertions werden aus einer lokalen ausführbaren Datei geladen. Die ausführbare Datei muss eine gültige, nicht abgelaufene SAML-Assertion im JSON-Format für stdout bereitstellen: 

    {
  "version": 1,
  "success": true,
  "token_type": "urn:ietf:params:oauth:token-type:saml2",
  "saml_response": "...",
  "expiration_time": 1620499962
}
    Diese Felder sind mit Ausnahme von expiration_time für eine erfolgreiche Antwort erforderlich. Das Feld expiration_time ist nur erforderlich, wenn in der Konfiguration der Anmeldedaten eine Ausgabedatei angegeben wurde.

    Wenn ein Fehler auftritt, muss dieser von der ausführbaren Datei im folgenden JSON-Format für stdout angezeigt werden: 

    {
  "version": 1,
  "success": false,
  "code": "401",
  "message": "Caller not authorized."
}
    Alle diese Felder sind für eine Fehlerantwort erforderlich. Die Code- und Nachrichtenfelder werden von den Clientbibliotheken verwendet, wenn der entsprechende Fehler ausgegeben wird.

    Zusammenfassung der Antwortformatfelder:

    • version: Die Version der JSON-Ausgabe. Derzeit wird nur Version 1 unterstützt.
    • success: Der Status der Antwort. Bei „true“ muss die Antwort das Token des Drittanbieters, den Tokentyp und das Ablaufdatum enthalten. Die ausführbare Datei muss auch mit dem Exit-Code 0 beendet werden. Bei „false“ muss die Antwort den Fehlercode und die Nachrichtenfelder enthalten und mit einem Wert ungleich Null beendet werden.
    • token_type: der Tokentyp des Drittanbieter-Subjekts. Muss urn:ietf:params:oauth:token-type:saml2 lauten.
    • saml_response: die SAML-Antwort des Drittanbieters.
    • expiration_time: die Ablaufzeit der SAML-Antwort des Drittanbieters in Sekunden (Unixzeit).
    • code: Der Fehlercodestring.
    • message: Die Fehlermeldung

    Die Clientbibliotheken füllen die folgenden Umgebungsvariablen, wenn die ausführbare Datei ausgeführt wird: * : GOOGLE_EXTERNAL_ACCOUNT_AUDIENCE: das Zielgruppenfeld aus der Anmeldedatenkonfiguration. Immer vorhanden. GOOGLE_EXTERNAL_ACCOUNT_TOKEN_TYPE: der erwartete Tokentyp des Subjekts. Immer vorhanden. * : GOOGLE_EXTERNAL_ACCOUNT_IMPERSONATED_EMAIL: die E-Mail-Adresse des Dienstkontos. Nur vorhanden, wenn die Identitätsübernahme des Dienstkontos verwendet wird. * : GOOGLE_EXTERNAL_ACCOUNT_OUTPUT_FILE: der Speicherort der Ausgabedatei aus der Konfiguration von Anmeldedaten. Nur vorhanden, wenn in der Konfiguration der Anmeldedaten angegeben.

    Diese Umgebungsvariablen können von der ausführbaren Datei verwendet werden, um eine Hartcodierung dieser Werte zu vermeiden.

    Um diese Methode der Anmeldedatenbereitstellung für die Clientbibliotheken zu aktivieren, muss die Umgebungsvariable GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES auf 1 festgelegt sein.

Führen Sie die folgenden Schritte aus, damit Clientbibliotheken oder Terraform Workload Identity-Föderation zur Authentifizierung verwenden:

  1. 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 Identitätsanbieter 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

      Ressourcenpfad: Anwendungs-ID-URI der Azure-Anwendung

      OIDC

      OIDC-Tokenpfad: lokaler Dateipfad oder URL, von der Anmeldedaten abgerufen werden sollen.

      Formattyp: Format der Datei oder URL-Antwort, aus der das ID-Token abgerufen wird.

      Name des Subject-Tokenfelds: Feld in der Antwort, das das Token enthält (wenn der Formattyp json ist).

      SAML

      SAML-Assertion-Pfad: lokaler Dateipfad oder URL zum Abrufen der Anmeldedaten.

      Formattyp: Format der Datei oder URL-Antwort, aus der die Assertion abgerufen wird.

      Assertion-Feldname: Feld in der Antwort mit der Assertion (wenn der Formattyp json ist).

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

    gcloud

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

    AWS

    Erstellen Sie eine Konfigurationsdatei für Anmeldedaten, mit der die Bibliothek ein Zugriffstoken aus den 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 die folgenden Werte:

    • PROJECT_NUMBER: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • FILEPATH: Datei, in der die Konfiguration gespeichert werden soll

    Wenn Sie AWS IMDSv2 verwenden, muss ein zusätzliches Flag --enable-imdsv2 zum Befehl gcloud iam workload-identity-pools create-cred-config 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

    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 die folgenden Werte:

    • PROJECT_NUMBER: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • APPLICATION_ID_URI: Anwendungs-ID-URI der Azure-Anwendung
    • FILEPATH: Datei, in der die Konfiguration gespeichert werden soll

    OIDC

    Um dateibasierte Anmeldedaten zu verwenden, nutzen Sie das Flag --credential-source-file:

    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 \
    --output-file=FILEPATH.json \
    --credential-source-file=TOKEN_FILEPATH \
    --credential-source-type=SOURCE_TYPE \
    --credential-source-field-name=FIELD_NAME

    Ersetzen Sie die folgenden Werte:

    • PROJECT_NUMBER: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • FILEPATH: Datei, in der die Konfiguration gespeichert werden soll
    • TOKEN_FILEPATH: Pfad, in dem OIDC-ID-Tokens gespeichert werden
    • SOURCE_TYPE: Format der OIDC-ID-Token-Datei, festgelegt auf text (Standard) oder json
    • FIELD_NAME: Feld in der Textdatei, die das Token enthält (wenn SOURCE_TYPE gleich json ist)

    Um URL-basierte Anmeldedaten zu verwenden, nutzen Sie das Flag --credential-source-url:

    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 \
    --output-file=FILEPATH.json \
    --credential-source-url="TOKEN_URL" \
    --credential-source-headers="KEY_1=VALUE_1,KEY_2=VALUE_2" \
    --credential-source-type=SOURCE_TYPE \
    --credential-source-field-name=FIELD_NAME

    Ersetzen Sie die folgenden Werte:

    • PROJECT_NUMBER: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • FILEPATH: Datei, in der die Konfiguration gespeichert werden soll
    • TOKEN_URL: URL, von der das OIDC-ID-Token abgerufen werden soll
    • KEY_n, VALUE_n: benutzerdefinierte Header, die in die HTTP-Anfrage an TOKEN_URL aufgenommen werden sollen
    • SOURCE_TYPE: Format der OIDC-ID-Token-Datei, festgelegt auf text (Standard) oder json
    • FIELD_NAME: Feld in der Textdatei, die das Token enthält (wenn SOURCE_TYPE gleich json ist)

    Um ausführbare Datei-basierte Anmeldedaten zu verwenden, nutzen Sie das Flag --executable-command:

    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 \
    --output-file=FILEPATH.json \
    --executable-command=EXECUTABLE_COMMAND \
    --executable-timeout-millis=EXECUTABLE_TIMEOUT \
    --executable-output-file=EXECUTABLE_OUTPUT_FILE

    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 Workload Identity-Poolanbieters
    • SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos.
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • FILEPATH: die Datei, in der die Konfiguration gespeichert werden soll
    • EXECUTABLE_COMMAND: der vollständige Befehl, einschließlich Argumenten, um das OIDC-ID-Token abzurufen (z. B. --executable-command="/path/to/command --foo=bar")
    • EXECUTABLE_TIMEOUT: die optionale Dauer in Millisekunden, die darauf gewartet wird, dass die ausführbare Datei ausgeführt wird (standardmäßig 30 Sekunden).
    • EXECUTABLE_OUTPUT_FILE: dieser Dateipfad verweist auf die 3PI-Anmeldedaten, die von der ausführbaren Datei generiert werden. Dies ist nützlich, um die Anmeldedaten im Cache zu speichern. Durch Angabe dieses Pfads prüfen die Auth-Bibliotheken zuerst, ob sie vorhanden sind, bevor die ausführbare Datei ausgeführt wird.

    OIDC (AD FS)

    Erstellen Sie eine Konfigurationsdatei für Anmeldedaten, mit der die Bibliothek das AD FS-Zugriffstoken aus der temporären Datei lesen 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 \
    --output-file=FILEPATH.json \
    --credential-source-file=TOKEN_FILEPATH \
    --credential-source-type=text

    Ersetzen Sie die folgenden Werte:

    • PROJECT_NUMBER: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • FILEPATH: Datei, in der die Konfiguration gespeichert werden soll
    • TOKEN_FILEPATH: Pfad zur temporären Datei, die das AD FS-Token enthält

    SAML

    Um dateibasierte Anmeldedaten zu verwenden, nutzen Sie das Flag --credential-source-file:

    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 \
    --output-file=FILEPATH.json \
    --credential-source-file=TOKEN_FILEPATH \
    --credential-source-type=SOURCE_TYPE \
    --credential-source-field-name=FIELD_NAME \
    --subject-token-type=urn:ietf:params:oauth:token-type:saml2

    Ersetzen Sie die folgenden Werte:

    • PROJECT_NUMBER: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • FILEPATH: Datei, in der die Konfiguration gespeichert werden soll
    • TOKEN_FILEPATH: Pfad, in dem SAML-Assertions gespeichert werden
    • SOURCE_TYPE: Format der SAML-Assertion-Datei, festgelegt auf text (Standard) oder json
    • FIELD_NAME: Feld in der Textdatei, die die Assertion enthält (wenn SOURCE_TYPE json ist)

    Um URL-basierte Anmeldedaten zu verwenden, nutzen Sie das Flag --credential-source-url:

    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 \
    --output-file=FILEPATH.json \
    --credential-source-url="TOKEN_URL" \
    --credential-source-headers="KEY_1=VALUE_1,KEY_2=VALUE_2" \
    --credential-source-type=source_type \
    --credential-source-field-name=field_name
    --subject-token-type=urn:ietf:params:oauth:token-type:saml2

    Ersetzen Sie die folgenden Werte:

    • PROJECT_NUMBER: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • FILEPATH: Datei, in der die Konfiguration gespeichert werden soll
    • TOKEN_URL: URL, von der die SAML-Assertion abgerufen werden soll
    • KEY_n, VALUE_n: benutzerdefinierte Header, die in die HTTP-Anfrage an TOKEN_URL aufgenommen werden sollen
    • SOURCE_TYPE: Format der SAML-Assertion-Datei, festgelegt auf text (Standard) oder json
    • FIELD_NAME: Feld in der Textdatei, die die Assertion enthält (wenn SOURCE_TYPE json ist)

    Um ausführbare Datei-basierte Anmeldedaten zu verwenden, nutzen Sie das Flag --executable-command:

    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 \
    --output-file=FILEPATH.json \
    --executable-command=EXECUTABLE_COMMAND \
    --executable-timeout-millis=EXECUTABLE_TIMEOUT \
    --executable-output-file=EXECUTABLE_OUTPUT_FILE

    Ersetzen Sie die folgenden Werte:

    • PROJECT_NUMBER: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos
    • SERVICE_ACCOUNT_TOKEN_LIFETIME: die gewünschte Lebensdauer des Dienstkonto-Zugriffstokens in Sekunden; beträgt standardmäßig 1 Stunde, wenn nicht angegeben. Wenn eine Lebensdauer von mehr als einer Stunde erforderlich ist, muss das Dienstkonto in einer Organisationsrichtlinie als zulässiger Wert hinzugefügt werden, der die Einschränkung constraints/iam.allowServiceAccountCredentialLifetimeExtension erzwingt.
    • FILEPATH: Datei, in der die Konfiguration gespeichert werden soll
    • EXECUTABLE_COMMAND: vollständiger Befehl zum Abrufen der SAML-Assertion
    • EXECUTABLE_TIMEOUT: die optionale Dauer in Millisekunden, die darauf gewartet wird, dass die ausführbare Datei ausgeführt wird (standardmäßig 30 Sekunden).
    • EXECUTABLE_OUTPUT_FILE: die optionale Ausgabedatei, in der die ausführbare Antwort gespeichert wird

    GitHub Actions

    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@v0.3.1'
  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: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos

    Beispiel:

    jobs:
  build:
    # Allow the job to fetch a GitHub ID token
    permissions:
      id-token: write
      contents: read

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v0.3.1'
        with:
          create_credentials_file: true
          workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
          service_account: 'SERVICE_ACCOUNT_EMAIL'

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

    YAML-Datei für GitHub Actions

    Die Aktion google-github-actions/auth initialisiert GOOGLE_APPLICATION_CREDENTIALS.

  3. Verwenden Sie eine Clientbibliothek, die Workload Identity-Föderation unterstützt und Anmeldedaten automatisch finden kann:

    C++

    Die meisten Google Cloud-Clientbibliotheken für C++ unterstützen die Identitätsföderation mithilfe eines ChannelCredentials-Objekts, das durch Aufrufen von grpc::GoogleDefaultCredentials() erstellt wird. Zur Initialisierung dieser Anmeldedaten müssen Sie die Clientbibliotheken ab Version 1.36.0 von gRPC erstellen.

    Da die Cloud Storage-Clientbibliothek für C++ die REST API und nicht gRPC verwendet, wird die Identitätsföderation nicht unterstützt.

    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 Identitätsfö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

    Dabei ist FILEPATH der 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 Föderation von Workload Identity, 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 den folgenden Abschnitt enthält:

    [Credentials]
gs_external_account_file = FILEPATH

    FILEPATH ist in beiden Fällen der 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 zum Authentifizieren der Workload Identity-Föderation den Befehl gcloud auth login:

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

    Dabei ist FILEPATH der 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.

Authentifizierung mithilfe der REST API

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 Identitätsanbieter 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. Regionale Endpunkte werden ebenfalls unterstützt.
    • method: die HTTP-Anfragemethode POST.
    • headers: die HTTP-Anfrageheader, die Folgendes enthalten müssen:
      • Authorization: die Anfragesignatur.
      • host: der Hostname des Felds url, z. B. sts.amazonaws.com.
      • x-amz-date: der 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():
    # 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.

    GitHub Actions

    Verwenden Sie google-github-actions/auth, um ein GitHub-ID-Token abzurufen und es gegen ein kurzlebiges Zugriffstoken auszutauschen:

    • 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 hinzu, um ein Zugriffstoken zu generieren und in einer Variablen ${{ steps.auth.outputs.access_token }} verfügbar zu machen:

      - id: 'auth'
  name: 'Authenticate to Google Cloud'
  uses: 'google-github-actions/auth@v0.3.1'
  with:
    token_format: 'access_token'
    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: 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
    • SERVICE_ACCOUNT_EMAIL: E-Mail-Adresse des Dienstkontos

    Beispiel:

    jobs:
  build:
    # Allow the job to fetch a GitHub ID token
    permissions:
      id-token: write
      contents: read

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v0.3.1'
        with:
          token_format: 'access_token'
          workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
          service_account: 'SERVICE_ACCOUNT_EMAIL'

    Überspringen Sie die folgenden Schritte.

    OIDC

    Rufen Sie ein Token von Ihrem externen Identitätsanbieter ab und initialisieren Sie die folgenden Variablen:

    Bash

    SUBJECT_TOKEN_TYPE="urn:ietf:params:oauth:token-type:jwt"
SUBJECT_TOKEN=TOKEN

    PowerShell

    $SubjectTokenType = "urn:ietf:params:oauth:token-type:jwt"
$SubjectToken = "TOKEN"

    Dabei ist TOKEN das Token, das von Ihrem externen Identitätsanbieter ausgestellt wurde.

    OIDC (AD FS)

    Mit den folgenden PowerShell-Befehlen authentifizieren Sie sich bei AD FS mithilfe von IWA und rufen ein Zugriffstoken ab:

    $SubjectTokenType = "urn:ietf:params:oauth:token-type:jwt"
$SubjectToken = (Invoke-RestMethod `
    -Uri "https://ADFS_DOMAIN/adfs/oauth2/token/" `
    -Method POST `
    -Body @{
        client_id = 'CLIENT_ID'
        grant_type = 'client_credentials'
        scope = 'openid'
        resource = 'RELYING_PARTY_ID'
        use_windows_client_authentication = 'true'
        } `
    -Credential USER).access_token

    Ersetzen Sie die folgenden Werte:

    • ADFS_DOMAIN: öffentlicher Domainname des AD FS-Servers oder der Farm.
    • CLIENT_ID: Client-ID der Anwendungsregistrierung in AD FS.
    • RELYING_PARTY_ID: Kennung der vertrauenswürdigen Partei, die Sie beim Erstellen einer Web API-Anwendung für den Workload Identity-Pool in AD FS verwendet haben. Sie benötigen diesen Parameter nur, wenn Sie eine benutzerdefinierte Kennung der vertrauenswürdigen Partei verwenden.
    • USER: Active Directory-Nutzer, der für IWA verwendet werden soll. Alternativ können Sie -Credential durch -UseDefaultCredentials ersetzen, um Ihre aktuellen Anmeldedaten zu verwenden.

    SAML

    Rufen Sie eine Assertion von Ihrem externen Identitätsanbieter ab und initialisieren Sie eine Variable:

    Bash

    SUBJECT_TOKEN_TYPE="urn:ietf:params:oauth:token-type:saml2"
SUBJECT_TOKEN=ASSERTION

    PowerShell

    $SubjectTokenType = "urn:ietf:params:oauth:token-type:saml2"
$SubjectToken = "ASSERTION"

    Dabei ist ASSERTION die base64-codierte Assertion, die von Ihrem externen Identitätsanbieter ausgegeben wird.

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

    Bash

    STS_TOKEN=$(curl -0 -X POST https://sts.googleapis.com/v1/token \
    -H 'Content-Type: text/json; charset=utf-8' \
    -d @- <<EOF | jq -r .access_token
    {
        "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"   : "$SUBJECT_TOKEN_TYPE",
        "subjectToken"       : "$SUBJECT_TOKEN"
    }
EOF
)
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: 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.

Externe Anmeldedaten prüfen

Security Token Service API führt die folgenden Schritte aus, um von einem externen Identitätsanbieter ausgestellte Anmeldedaten zu prüfen.

AWS

  • Prüfen Sie die folgenden Felder im GetCallerIdentity-Token:

    • Die url sollte ein HTTPS-URI mit einem Hostnamen gleich sts.amazonaws.com (oder einer regionalen Subdomain) und keinem Port sein. Die folgenden Abfrageparameter sind vorhanden:
      • action = getcalleridentity
      • version (beliebiger Wert)
    • Der method ist POST.
    • Die folgenden headers sind vorhanden: x-amz-date, authorization, host, x-goog-cloud-target-resource, x-amz-security-token (optional)
      • Der Wert von x-goog-cloud-target-resource ist der Ressourcenname für den Workload Identity-Poolanbieter.
      • Der Wert von x-amz-date liegt höchstens 15 Minuten in der Vergangenheit und nicht in der Zukunft.

  • Führen Sie die Anfrage für sts.amazonaws.com oder die relevante regionale Subdomain aus und prüfen Sie, ob das Ergebnis erfolgreich ist und die AWS-Konto-ID mit der konfigurierten Konto-ID für den Workload Identity-Poolanbieter übereinstimmt.

Azure

Azure-Tokens sind OIDC-Tokens und werden auf die gleiche Weise wie OIDC-Tokens verifiziert.

GitHub Actions

GitHub-Tokens sind OIDC-Tokens und werden auf die gleiche Weise wie OIDC-Tokens verifiziert.

OIDC

OIDC-Tokens werden gemäß der OIDC-Spezifikation verifiziert. Der Security Token Service führt insbesondere die folgenden Schritte aus:

  • Discovery-Dokument und Signaturprüfung:

    • Erstellen Sie den URI des Discovery-Endpunkts, indem Sie /.well-known/openid-configuration an den im Workload Identity-Poolanbieter konfigurierten Aussteller anhängen und das OIDC-Discovery-Dokument abrufen.
    • Prüfen Sie, ob die Anforderung issuer im Discovery-Dokument mit dem Aussteller übereinstimmt, der im Workload Identity-Poolanbieter konfiguriert ist. STS hat eine benutzerdefinierte Verifizierungslogik für die folgenden Aussteller, die nicht der OIDC-Spezifikation entsprechen:
      • Oracle Cloud (https://*.identity.oraclecloud.com)
      • Microsoft (https://login.microsoftonline.com/common/v2.0, https://login.microsoftonline.com/consumers/v2.0, https://login.microsoftonline.com/organizations/v2.0)
    • Rufen Sie das JSON Web Key Set (JWKS) aus dem im Discovery-Dokument aufgeführten jwks_uri ab.
    • Wenn der JWT-Header eine kid-Anforderung enthält, prüfen Sie die JWT-Signatur mit dem Schlüssel aus dem JWKS mit der übereinstimmenden Schlüssel-ID oder lehnen Sie das Token ab, wenn kein übereinstimmender Schlüssel gefunden wird. Wenn im JWT-Header keine kid-Anforderung vorhanden ist, versuchen Sie, die JWT-Signatur mit jedem im JWKS aufgeführten Schlüssel zu prüfen. Die Signatur wird akzeptiert, wenn ein Schlüssel zum Überprüfen der Signatur verwendet werden kann.

  • Header-Überprüfung:

    • Eine alg-Anforderung muss vorhanden sein und entweder RS256 oder ES256 entsprechen.

  • Nutzlastprüfung:

    • Eine iss-Anforderung muss vorhanden sein und der issuer-Anforderung im Discovery-Dokument entsprechen. STS hat eine benutzerdefinierte Verifizierungslogik für die folgenden Aussteller, die nicht der OIDC-Spezifikation entsprechen:
      • Oracle Cloud (https://*.identity.oraclecloud.com)
      • Microsoft (https://login.microsoftonline.com/common/v2.0, https://login.microsoftonline.com/consumers/v2.0, https://login.microsoftonline.com/organizations/v2.0)
    • Eine aud-Anforderung muss vorhanden sein und entspricht https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID. Wenn alternative allow_audiences konfiguriert sind, muss die aud-Anforderung stattdessen einem dieser Werte entsprechen.
    • Eine exp-Anforderung muss vorhanden sein und in der Zukunft liegen.
    • Eine iat-Anforderung muss vorhanden sein und in der Vergangenheit liegen.
    • Der Wert von exp muss um höchstens 24 Stunden größer als der Wert von iat sein.

SAML

  • Base64-Dekodierung und Umwandlung der SAML-Anmeldedaten in ein Response- oder Assertion-Objekt.

  • Wenn die SAML-Anmeldedaten in ein Response-Objekt umgewandelt werden, prüfen Sie Folgendes:

    • Der Antwort-StatusCode entspricht urn:oasis:names:tc:SAML:2.0:status:Success.
    • Es ist genau ein Assertion vorhanden.
    • Mindestens ein Response oder Assertion ist signiert. Versuchen Sie für jede Signatur, die Signatur mit jedem im Workload Identity Pool Provider konfigurierten X.509-Zertifikat zu prüfen. Die Signatur wird akzeptiert, wenn eines der Zertifikate die Signatur erfolgreich überprüft.
    • Wenn die Response signiert ist, muss die Issuer von Response vorhanden sein und der Entitäts-ID des SAML-Identitätsanbieters entsprechen, die im Workload Identity-Poolanbieter konfiguriert ist. Prüfen Sie auch, ob Format entweder ausgelassen wurde oder gleich urn:oasis:names:tc:SAML:2.0:nameid-format:entity ist.

  • Wenn die SAML-Anmeldedaten in ein Assertion-Objekt umgewandelt werden, prüfen Sie Folgendes:

    • Assertion wird signiert. Versuchen Sie für jede Signatur, die Signatur mit jedem im Workload Identity-Poolanbieter konfigurierten X.509-Zertifikat zu prüfen. Die Signatur wird akzeptiert, wenn eines der Zertifikate die Signatur erfolgreich überprüft.

  • Unabhängig davon, ob die SAML-Anmeldedaten in ein Response- oder Assertion-Objekt umgewandelt wurden, prüfen Sie, ob Assertion die folgenden Attribute enthält:

    • Ein Issuer muss vorhanden sein und entspricht der Entitäts-ID des SAML-Identitätsanbieters, die im Workload Identity-Poolanbieter konfiguriert ist. Der Format von Issuer wird entweder weggelassen oder hat einen Wert, der urn:oasis:names:tc:SAML:2.0:nameid-format:entity entspricht.
    • Ein IssueInstant muss vorhanden sein und liegt weniger als eine Stunde in der Vergangenheit.
    • Ein Subject muss vorhanden sein und die folgenden Attribute enthalten:
      • Ein NameID muss vorhanden sein.
      • Es muss genau eine SubjectConfirmation vorhanden sein, deren Method gleich urn:oasis:names:tc:SAML:2.0:cm:bearer ist. Ein NotOnOrAfter muss in SubjectConfirmationData vorhanden sein und in der Zukunft liegen.
      • Ein NotBefore ist nicht vorhanden.
    • Ein Conditions muss vorhanden sein und die folgenden Attribute enthalten:
      • Wenn ein NotBefore vorhanden ist, muss es in der Vergangenheit liegen.
      • Wenn ein NotOnOrAfter vorhanden ist, muss es in der Zukunft liegen.
      • Mindestens ein AudienceRestriction muss vorhanden sein. Alle AudienceRestriction-Elemente müssen einen Audience enthalten, der dem Ressourcennamen des Workload Identity-Poolanbieters entspricht.
    • Mindestens ein AuthnStatement muss vorhanden sein.
    • Wenn SessionNotOnOrAfter vorhanden sind, müssen alle in der Zukunft liegen.

Zusätzlich zu den protokollspezifischen Überprüfungsschritten oben prüft die Security Token Service API auch, ob die Attributbedingung erfüllt wird.

Nächste Schritte