Workload Identity-Föderation mit anderen Identitätsanbietern konfigurieren

In diesem Leitfaden wird beschrieben, wie Sie die Workload Identity-Föderation mit anderen Identitätsanbietern (IdPs) verwenden.

Arbeitslasten, die außerhalb von Google Cloud ausgeführt werden, haben möglicherweise Zugriff auf vorhandene umgebungsspezifische Anmeldedaten. Beispiele:

Eine Arbeitslast kann möglicherweise ein SAML-Assertion- oder OIDC-Token (OpenID Connect) von einem Identitätsanbieter (IdP) abrufen, der in derselben Umgebung ausgeführt wird.

Zur Authentifizierung bei Google Cloud können Sie die Arbeitslast mit der Workload Identity-Föderation ihre umgebungsspezifischen Anmeldedaten gegen kurzlebige Google Cloud-Anmeldedaten austauschen lassen.
Eine Arbeitslast kann andere Arten von Anmeldedaten haben, z. B. ein mTLS-Clientzertifikat.

Wenn Sie die Workload Identity-Föderation mit einem benutzerdefinierten Token-Broker kombinieren, können Arbeitslasten andere Arten von Anmeldedaten verwenden, um kurzlebige Google Cloud-Anmeldedaten abzurufen.

Mit Workload Identity-Föderation können Sie die Anzahl der zu rotierenden Anmeldedaten reduzieren.

In den folgenden Abschnitten wird beschrieben, wie Sie die Workload Identity-Föderation mit IdPs verwenden, die entweder Open-Source-OIDC- oder SAML-Authentifizierungsprotokolle unterstützen.

Externen IdP vorbereiten

Sie müssen diese Schritte nur einmal für jeden IdP ausführen.

Prüfen Sie zuerst, ob Ihr externer IdP folgende Anforderungen erfüllt:

OIDC

Der IdP unterstützt OpenID Connect 1.0.
Die OIDC-Metadaten und -JWKS-Endpunkte des IdP werden mit SSL und TLS gesichert, die Endpunkt-URLs beginnen mit https:// und die Endpunkte sind über das Internet öffentlich zugänglich.

Google Cloud verwendet diese Endpunkte zum Herunterladen des Schlüsselsatzes Ihres IdP und nutzt diesen Schlüsselsatz, um Tokens zu validieren.

Endpunkte, die mit selbst signierten Zertifikaten gesichert sind, werden von Google Cloud nicht unterstützt.

SAML

Der IdP unterstützt SAML 2.0.
Der IdP bietet ein SAML SP-Metadatendokument, in dem die Konfiguration des SAML-Dienstanbieters beschrieben wird. Das Dokument enthält auch das Signaturzertifikat des IdP.

Google Cloud verwendet dieses Zertifikat, um SAML-Assertions und -Antworten zu validieren.

Wenn Ihr IdP diese Kriterien erfüllt, gehen Sie so vor:

OIDC

Konfigurieren Sie Ihren IdP so, dass Ihre Arbeitslast ID-Tokens erhalten kann, die folgende Kriterien erfüllen:

Tokens werden mit einem der Algorithmuen RS256 oder ES256 signiert.
Tokens enthalten eine aud-Anforderung mit folgendem Wert:
```
https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
```
Ersetzen Sie Folgendes:
- PROJECT_NUMBER: Projektnummer des Google Cloud-Projekts, mit dem Sie einen Workload Identity-Pool erstellen.
- POOL_ID: ID Ihrer Wahl, die den Workload Identity-Pool identifiziert. Sie müssen dieselbe ID verwenden, wenn Sie später den Workload Identity-Pool erstellen.
- PROVIDER_ID: ID Ihrer Wahl, die den Anbieter des Workload Identity-Pools identifiziert. Sie müssen dieselbe ID verwenden, wenn Sie später den Anbieter des Workload Identity-Pools erstellen.
Alternativ können Sie den Anbieter des Workload Identity-Pools so konfigurieren, dass eine benutzerdefinierte Zielgruppe erwartet wird.
Tokens enthalten eine exp-Anforderung, die in der Zukunft liegt, und eine iat-Anforderung, die in der Vergangenheit liegt.

Der Wert von exp muss um höchstens 24 Stunden größer als der Wert von iat sein.

In der Regel ist es am besten, ID-Tokens zu verwenden, wenn ein Tokenaustausch durchgeführt wird, da ID-Tokens die Identität des Nutzers widerspiegeln. Wenn Sie stattdessen Zugriffstokens verwenden möchten, achten Sie darauf, dass die Zugriffstokens folgende zusätzliche Anforderungen erfüllen:

Zugriffstokens sind als JSON-Webtoken formatiert
Zugriffstokens enthalten eine ISSUER-Anforderung, sodass die URL ISSUER/.well-known/openid-configuration auf den OIDC-Metadaten-Endpunkt des IdP verweist.
Informationen zum Hochladen lokaler JWK-Schlüssel finden Sie unter OIDC-JWKs verwalten.

SAML

Konfigurieren Sie Ihren IdP so, dass SAML-Assertions Elemente enthalten, die folgende Kriterien erfüllen:

Ein Issuer-Element, das auf die Entitäts-ID gesetzt ist, die im Workload Identity-Poolanbieter konfiguriert ist. Das Ausstellerformat muss ausgelassen oder auf urn:oasis:names:tc:SAML:2.0:nameid-format:entity gesetzt werden.
Ein Subject-Element mit:
- Ein NameID-Element.
- Genau ein SubjectConfirmation-Element, wobei Method auf urn:oasis:names:tc:SAML:2.0:cm:bearer gesetzt ist.
- Ein SubjectConfirmationData-Element, bei dem NotOnOrAfter auf einen Zeitstempel in der Zukunft gesetzt ist, und ohne NotBefore-Wert.
Ein Conditions-Element mit:
- NotBefore wurde weggelassen oder liegt in der Vergangenheit.
- NotOnOrAfter wurde weggelassen oder liegt in der Zukunft.
- Ein Audience, der so formatiert ist:
```
https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
```
  Ersetzen Sie Folgendes:
  - PROJECT_NUMBER: Projektnummer des Google Cloud-Projekts, mit dem Sie einen Workload Identity-Pool erstellen.
  - POOL_ID: ID Ihrer Wahl, die den Workload Identity-Pool identifiziert. Sie müssen dieselbe ID verwenden, wenn Sie später den Workload Identity-Pool erstellen.
  - PROVIDER_ID: ID Ihrer Wahl, die den Anbieter des Workload Identity-Pools identifiziert. Sie müssen dieselbe ID verwenden, wenn Sie später den Anbieter des Workload Identity-Pools erstellen.
Mindestens ein AuthnStatement-Element
Ein SessionNotOnOrAfter-Element mit einem Zeitstempel, der in der Zukunft liegt. Alternativ können Sie das Element weglassen.

Für SAML-Assertions, die in einer SAML-Antwort enthalten sind, muss die SAML-Antwort Folgendes enthalten:

Genau eine Assertion, die die zuvor in diesem Abschnitt beschriebenen SAML-Assertion-Kriterien erfüllt.
Ein IssueInstant-Attribut mit einem Wert, der weniger als 1 Stunde in der Vergangenheit liegt.
Den Statuscode urn:oasis:names:tc:SAML:2.0:status:Success.

Es müssen entweder die SAML-Assertion, die Antwort oder beides signiert sein.

Identitätsföderation von Arbeitslasten konfigurieren

Sie müssen diese Schritte nur einmal für jeden IdP 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:

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

Go to project selector

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

Make sure that billing is enabled for your Google Cloud project.

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

Enable the APIs

OIDC-JWKs verwalten (optional)

In diesem Abschnitt erfahren Sie, wie Sie selbst hochgeladene OIDC-JWKs in Workload Identity-Pool-OIDC-Anbietern verwalten.

Anbieter erstellen und OIDC-JWKs hochladen

Informationen zum Erstellen von OIDC-JWKs finden Sie unter JWT-, JWS-, JWE-, JWK- und JWA-Implementierungen.

Zum Hochladen einer OIDC-JWK-Datei beim Erstellen eines Workload Identity-Poolanbieters führen Sie den Befehl gcloud iam workload-identity-pools providers create-oidc mit --jwk-json-path="JWK_JSON_PATH" aus. Ersetzen Sie JWK_JSON_PATH durch den Pfad zur JWKs-JSON-Datei.

Bei diesem Vorgang werden hochgeladene Schlüssel mit den Schlüsseln in der Datei erstellt.

OIDC-JWKs aktualisieren

Zum Aktualisieren von OIDC JWKs führen Sie den Befehl gcloud iam workloads-identity-pools providers update-oidc mit --jwk-json-path="JWK_JSON_PATH" aus. Ersetzen Sie JWK_JSON_PATH durch den Pfad zur JWKs-JSON-Datei.

Dieser Vorgang ersetzt alle vorhandenen hochgeladenen Schlüssel durch die in der Datei. Die ersetzten Schlüssel können nicht wiederhergestellt werden.

Alle hochgeladenen OIDC-JWKs löschen

Um alle hochgeladenen OIDC-JWKs zu löschen und wieder die Aussteller-URI zum Abrufen der Schlüssel zu verwenden, führen Sie den Befehl gcloud iam workload-identity-pools providers update-oidc mit --jwk-json-path="JWK_JSON_PATH"aus. Ersetzen Sie JWK_JSON_PATH durch den Pfad zu einer leeren Datei. Mit dem Flag --issuer-uri können Sie den Aussteller-URI festlegen.

Bei diesem Vorgang werden alle bereits hochgeladenen Schlüssel mit den Schlüsseln in der Datei gelöscht. Sie können die gelöschten Schlüssel nicht wiederherstellen.

Attributzuordnung und -bedingung definieren

Die von Ihrem IdP ausgestellten OIDC-Tokens oder SAML-Assertions können mehrere Attribute enthalten. Sie müssen entscheiden, welches Attribut Sie in Google Cloud als Subjekt-ID (google.subject) verwenden möchten.

Optional können Sie zusätzliche Attribute zuordnen. Sie können dann auf diese Attribute verweisen, wenn Sie Zugriff auf Ressourcen gewähren.

OIDC

Ihre Attributzuordnungen können die in dem ID-Token oder Zugriffstoken eingebetteten Anforderungen des externen IdP verwenden.

Sie müssen eine dieser Anforderungen google.subject zuordnen, um den Nutzer eindeutig zu identifizieren. Wählen Sie zum Schutz vor Spoofing-Bedrohungen eine Anforderung mit einem eindeutigen Wert aus, der nicht geändert werden kann.

Viele IdPs füllen die sub-Anforderung mit einer eindeutigen und unveränderlichen ID auf. Erwägen Sie für diese IdPs, die sub-Anforderung google.subject zuzuordnen:

google.subject=assertion.sub

Vermeiden Sie zu diesem Zweck eine Anforderung wie email. E-Mail-Adressen können in der Regel neu zugewiesen oder geändert werden, um Nutzer nicht eindeutig und dauerhaft zu identifizieren.

SAML

Ihre Attributzuordnungen können die Elemente <Subject> und <Attribute> nutzen, die in die vom externen IdP ausgegebene Assertion eingebettet sind. SAML-Attribute können mit den folgenden Suchbegriffen referenziert werden:

assertion.subject enthält die NameID des authentifizierten Nutzers, der im Element <Subject> enthalten ist.
assertion.attributes['ATTRIBUTE_NAME'] enthält eine Liste von Werten für das gleichnamige <Attribute>.

Viele IdPs befüllen die NameId mit einer eindeutigen und unveränderlichen ID. Erwägen Sie bei solchen IdPs, das NameId-Attribut google.subject zuzuordnen:

google.subject=assertion.subject

Verwenden Sie zu diesem Zweck kein Attribut wie http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. Da E-Mail-Adressen in der Regel neu zugewiesen oder geändert werden können, eignen Sie sich nicht dazu, Nutzer eindeutig und dauerhaft zu identifizieren.

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.

OIDC

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

Die folgende Bedingung beschränkt beispielsweise den Zugriff auf Tokens, die eine benutzerdefinierte service_account-Anforderung mit einem true-Wert enthalten:

assertion.service_account==true

SAML

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

Die folgende Bedingung beschränkt beispielsweise den Zugriff auf Assertions, die ein benutzerdefiniertes https://example.com/SAML/Attributes/AllowGcpFederation-Attribut mit dem Wert true enthalten:

assertion.attributes['https://example.com/SAML/Attributes/AllowGcpFederation'][0]=='true'

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:

Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)
Service Account Admin (roles/iam.serviceAccountAdmin)

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

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

Zum neuen Arbeitslastanbieter und -anbieterpool
Geben Sie unter Identity-Pool erstellen Folgendes ein:
- Name: ist der Name für den Pool. Der Name wird auch als Pool-ID verwendet. Sie können die Pool-ID später nicht ändern.
- Beschreibung: Text, der den Zweck des Pools beschreibt.
Klicken Sie auf Weiter.
Konfigurieren Sie die Anbietereinstellungen so:
OIDC
- Wählen Sie unter Anbieter auswählen die Option OpenID Connect (OIDC) aus.
- Geben Sie unter Anbietername einen Namen für den Anbieter ein. Der Name wird auch als Anbieter-ID verwendet. Sie können die Anbieter-ID nicht mehr ändern, nachdem der Anbieter erstellt wurde.
- Geben Sie unter Aussteller-URL die Aussteller-URL Ihres IdP ein. Die URL muss mit https:// beginnen.
- Optional: Wählen Sie in JWK-Datei (JSON) eine JWK-Datei zum Hochladen aus. Wenn dieses Feld nicht angegeben ist, versucht Google Cloud, einen JWK vom Aussteller abzurufen.
- Zulässige Zielgruppen: Erwartete Zielgruppe von ID-Tokens.
SAML
- Wählen Sie unter Anbieter auswählen die Option SAML aus.
- Geben Sie unter Anbietername einen Namen für den Anbieter ein. Der Name wird auch als Anbieter-ID verwendet. Sie können die Anbieter-ID nicht mehr ändern, nachdem der Anbieter erstellt wurde.
- Laden Sie in der Datei IdP-Metadaten (XML) das XML-Dokument mit den SAML-Metadaten hoch, das von Ihrem Identitätsanbieter bereitgestellt wird.
Klicken Sie auf Weiter.
Fügen Sie unter Anbieterattribute konfigurieren die Attributzuordnungen hinzu, die Sie zuvor in dieser Anleitung identifiziert haben.
Geben Sie unter Attributbedingungen die Attributbedingung ein, die Sie zuvor in dieser Anleitung identifiziert haben. Lassen Sie das Feld leer, wenn Sie keine Attributbedingung haben.
Klicken Sie zum Erstellen des Workload Identity-Pools und -Anbieters auf Speichern.

gcloud

Führen Sie folgenden Befehl aus, um einen neuen Workload Identity-Pool zu erstellen:
```
gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
Ersetzen Sie Folgendes:
- POOL_ID: die eindeutige ID des Pools.
- DISPLAY_NAME: der Name des Pools.
- DESCRIPTION: eine Beschreibung des von Ihnen gewählten Pools. Diese Beschreibung wird angezeigt, wenn Sie Zugriff auf Poolidentitäten gewähren.
So fügen Sie einen Workload Identity-Poolanbieter hinzu:
OIDC
Führen Sie folgenden Befehl aus, um einen OIDC-Workload Identity-Pool-Anbieter hinzuzufügen:
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --allowed-audiences="AUDIENCE" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
    --jwk-json-path="JWK_JSON_PATH"
```
Ersetzen Sie Folgendes:
- PROVIDER_ID: eine eindeutige Anbieter-ID für Workload Identity-Pool Ihrer Wahl.
- POOL_ID: die ID des Workload Identity-Pools, die Sie zuvor erstellt haben.
- ISSUER: Ein Aussteller-URI, wie er in den OIDC-Metadaten definiert ist.
- AUDIENCE: Die erwartete Zielgruppe von ID-Tokens, die bei vielen Anbietern mit der Client-ID übereinstimmen.
- MAPPINGS: eine durch Kommas getrennte Liste der Attributzuordnungen, die Sie zuvor in dieser Anleitung erstellt haben.
- CONDITIONS: eine optionale Attributbedingung, die Sie zuvor in dieser Anleitung erstellt haben. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
- JWK_JSON_PATH: Ein optionaler Pfad zu einem lokal hochgeladenen OIDC-JWKS. Wenn dieser Parameter nicht angegeben ist, verwendet Google Cloud stattdessen den Pfad /.well-known/openid-configuration Ihres IdP, um den JWKS mit den öffentlichen Schlüsseln zu ermitteln.
SAML
Führen Sie folgenden Befehl aus, um einen SAML-Workload Identity-Poolanbieter hinzuzufügen:
```
gcloud iam workload-identity-pools providers create-saml PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --idp-metadata-path="IDP_METADATA_PATH" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Ersetzen Sie Folgendes:
- POOL_ID: die ID des Pools.
- IDP_METADATA_PATH: der lokale Pfad zum Metadatendokument des SAML-IdP
- MAPPINGS: eine durch Kommas getrennte Liste der Attributzuordnungen, die Sie zuvor in dieser Anleitung erstellt haben.
- CONDITIONS (optional): die Attributbedingung, die Sie zuvor in dieser Anleitung erstellt haben.
Das Präfix gcp- ist reserviert und kann nicht in einem Pool oder einer Anbieter-ID verwendet werden.

Optional: Verschlüsselte SAML-Assertions von Ihrem IdP akzeptieren

So ermöglichen Sie Ihrem SAML 2.0-IdP, verschlüsselte SAML-Assertions zu erstellen, die von der Workload Identity-Föderation akzeptiert werden:
- Gehen Sie in der Workload Identity-Föderation so vor:
- Gehen Sie bei Ihrem IdP so vor:
Beachten Sie, dass die Workload Identity-Föderation auch dann eine Klartext-Assertion verarbeiten kann, wenn SAML-Verschlüsselungsanbieterschlüssel konfiguriert sind.

SAML-Assertion-Verschlüsselungsschlüssel für die Workload Identity-Föderation erstellen

In diesem Abschnitt wird beschrieben, wie Sie ein asymmetrisches Schlüsselpaar erstellen, mit dem die Workload Identity-Föderation verschlüsselte SAML-Assertions akzeptieren kann.

Google Cloud verwendet den privaten Schlüssel zum Entschlüsseln der SAML-Assertions, die Ihr IdP ausgibt. Führen Sie den folgenden Befehl aus, um ein asymmetrisches Schlüsselpaar für die Verwendung mit der SAML-Verschlüsselung zu erstellen. Weitere Informationen finden Sie unter Unterstützte SAML-Verschlüsselungsalgorithmen.
```
gcloud iam workload-identity-pools providers keys create KEY_ID \
    --workload-identity-pool WORKLOAD_POOL_ID \
    --provider PROVIDER_ID \
    --location global \
    --use encryption \
    --spec KEY_SPECIFICATION
```
Ersetzen Sie Folgendes:
- KEY_ID: ein Schlüsselname Ihrer Wahl
- WORKLOAD_POOL_ID: die Pool-ID
- PROVIDER_ID: die Anbieter-ID
- KEY_SPECIFICATION: die Schlüsselspezifikation, entweder rsa-2048, rsa-3072 oder rsa-4096
Führen Sie nach dem Erstellen des Schlüsselpaars den folgenden Befehl aus, um den öffentlichen Schlüssel in eine Zertifikatsdatei herunterzuladen. Nur die Workload Identity-Föderation hat Zugriff auf den privaten Schlüssel.
```
gcloud iam workload-identity-pools providers keys describe KEY_ID \
    --workload-identity-pool WORKLOAD_POOL_ID \
    --provider PROVIDER_ID \
    --location global \
    --format "value(keyData.key)" \
    > CERTIFICATE_PATH
```
Ersetzen Sie Folgendes:
- KEY_ID: der Schlüsselname
- WORKLOAD_POOL_ID: die Pool-ID
- PROVIDER_ID: die Anbieter-ID
- CERTIFICATE_PATH: der Pfad, in den das Zertifikat geschrieben werden soll, z. B. saml-certificate.cer oder saml-certificate.pem
SAML 2.0-konformen IdP für die Ausgabe verschlüsselter SAML-Assertions konfigurieren

Konfigurieren Sie Ihren SAML-IdP so, dass er das im letzten Schritt heruntergeladene öffentliche Zertifikat verwendet, um die ausgegebenen SAML-Assertions zu verschlüsseln. Wenden Sie sich an Ihr IdP-Team, um eine spezifische Anleitung zu erhalten.

Nachdem Sie Ihren IdP so konfiguriert haben, dass SAML-Assertions verschlüsselt werden, sollten Sie prüfen, ob die generierten Assertions tatsächlich verschlüsselt sind. Die Workload Identity-Föderation kann weiterhin Klartext-Assertions verarbeiten, auch wenn die SAML-Assertion-Verschlüsselung konfiguriert ist.

Verschlüsselungsschlüssel der Workload Identity-Föderation löschen
Führen Sie den folgenden Befehl aus, um SAML-Verschlüsselungsschlüssel zu löschen:
```
  gcloud iam workload-identity-pools providers keys delete KEY_ID \
      --workload-identity-pool WORKLOAD_POOL_ID \
      --provider PROVIDER_ID \
      --location global
```
Ersetzen Sie Folgendes:
- KEY_ID: der Schlüsselname
- WORKLOAD_POOL_ID: die Pool-ID
- PROVIDER_ID: die Anbieter-ID
Unterstützte SAML-Verschlüsselungsalgorithmen

Die Workforce Identity-Föderation unterstützt die folgenden Schlüsseltransportalgorithmen:
Die Workload Identity-Föderation unterstützt die folgenden Blockverschlüsselungsalgorithmen:

Arbeitslast authentifizieren

Sie müssen diese Schritte einmal für jede Arbeitslast ausführen.

Externer Arbeitslast den Zugriff auf Google Cloud-Ressourcen erlauben

Damit Ihre Arbeitslast Zugriff auf Google Cloud-Ressourcen erhält, sollten Sie dem Hauptkonto direkten Ressourcenzugriff gewähren. In diesem Fall ist das Hauptkonto der föderierte Nutzer. Einige Google Cloud-Produkte unterliegen Google Cloud API-Einschränkungen. Wenn Ihre Arbeitslast einen API-Endpunkt mit einer Einschränkung aufruft, können Sie stattdessen die Identitätsübernahme des Dienstkontos verwenden. In diesem Fall ist das Hauptkonto das Google Cloud-Dienstkonto, das als Identität fungiert. Sie gewähren dem Dienstkonto Zugriff auf die Ressource.

Direkter Ressourcenzugriff

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

Console

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

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

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

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

gcloud

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

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

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

Gewähren Sie Zugriff auf die Ressource.

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

Hinweis: Sie müssen in der Mitglieds-ID die Projektnummer, nicht die Projekt-ID, verwenden.

Identitätsübertragung für ein Dienstkonto

So erstellen Sie ein Dienstkonto für die externe Arbeitslast:
1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.
  Enable the APIs
2. Erstellen Sie ein Dienstkonto, das die Arbeitslast darstellt. Es empfiehlt sich, für jede Arbeitslast ein dediziertes Dienstkonto zu verwenden.
  
  Das Dienstkonto muss sich nicht im selben Projekt wie der Workload Identity-Pool befinden.
3. Gewähren Sie dem Dienstkonto Zugriff auf Ressourcen, auf die externe Identitäten zugreifen können sollen.
4. Weisen Sie dem Dienstkonto die Nutzerrolle "Workload Identity" (roles/iam.workloadIdentityUser) zu.
5. Erstellen Sie ein Dienstkonto, das die Arbeitslast darstellt. Wir empfehlen, für jede Arbeitslast ein dediziertes Dienstkonto zu verwenden.
  
  Das Dienstkonto muss sich nicht im selben Projekt wie der Workload Identity-Pool befinden. Sie müssen sich aber auf das Projekt beziehen, das das Dienstkonto enthält.
So gewähren Sie Zugriff auf eine föderierte Identität mithilfe der Identitätsübernahme des Dienstkontos über die Google Cloud Console oder die gcloud CLI:
Console
So weisen Sie der Google Cloud Console IAM-Rollen zu, um einer föderierten Identität mit einem Dienstkonto IAM-Rollen zuzuweisen:
1. Erstellen Sie ein Dienstkonto, das als Identität für die Identitätsübernahme dient. Gehen Sie dazu so vor:
  1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.
    Enable the APIs
  2. Erstellen Sie ein Dienstkonto, das die Identität für die Arbeitslast darstellt. Wir empfehlen, für jede Arbeitslast ein dediziertes Dienstkonto zu verwenden.
    
    Das Dienstkonto muss sich nicht im selben Projekt wie der Workload Identity-Pool befinden. Wenn Sie jedoch IAM-Zugriff gewähren, müssen Sie auf das Projekt verweisen, das das Dienstkonto enthält.
  3. Gewähren Sie dem Dienstkonto Zugriff auf Ressourcen, auf die externe Identitäten zugreifen können sollen.
2. So gewähren Sie Zugriff über die Dienstkonto-Identitätsübernahme:
  1. Rufen Sie die Seite Workload Identity-Pools auf.
    
    Zu Workload Identity-Pools
  2. Wählen Sie Zugriff erlauben aus.
  3. Wählen Sie im Dialogfeld Zugriff auf Dienstkonto gewähren die Option Zugriff mit Identitätsübernahme des Dienstkontos gewähren aus.
  4. Wählen Sie in der Liste Dienstkonten das Dienstkonto aus, das von den externen Identitäten übernommen werden soll. Gehen Sie dann so vor:
  5. Führen Sie eine der folgenden Aktionen aus, um auszuwählen, welche Identitäten im Pool die Identität des Dienstkontos übernehmen können:
    
    Damit nur bestimmte Identitäten des Workload Identity-Pools die Identität des Dienstkontos übernehmen können, wählen Sie Nur Identitäten, die dem Filter entsprechen aus.
    
    Wählen Sie in der Liste Attributname das Attribut aus, nach dem Sie filtern möchten.
    
    Geben Sie im Feld Attributwert den erwarteten Wert des Attributs ein. Wenn Sie beispielsweise eine google.subject=assertion.sub-Attributzuordnung verwenden, legen Sie den Attributnamen auf subject und den Attributwert auf den Wert der sub-Anforderung in Tokens fest, die von Ihrem externen Identitätsanbieter ausgestellt werden.
  6. Klicken Sie zum Speichern der Konfiguration auf Speichern und dann auf Schließen.
gcloud

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

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
Nach Gruppe

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
Nach Attribut

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
Ersetzen Sie Folgendes:
- SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos.
- PROJECT_NUMBER: die Projektnummer des Projekts, das den Workload Identity-Pool enthält
- POOL_ID: die Pool-ID des Workload Identity-Pools
- SUBJECT: der erwartete Wert für das Attribut, das Sie google.subject zugeordnet haben
- GROUP: der erwartete Wert für das Attribut, das Sie google.groups zugeordnet haben
- ATTRIBUTE_NAME: der Name eines benutzerdefinierten Attributs in Ihrer Attributzuordnung
- ATTRIBUTE_VALUE: Wert des benutzerdefinierten Attributs in Ihrer Attributzuordnung
Hinweis: Sie müssen in der Mitglieds-ID die Projektnummer, nicht die Projekt-ID, verwenden.

Konfiguration von Anmeldedaten herunterladen

In diesem Abschnitt wird beschrieben, wie Sie die Konfiguration von Anmeldedaten mithilfe der Google Cloud Console herunterladen.

Damit Ihre Arbeitslast auf Clientbibliotheken zugreifen kann, müssen Sie zuerst die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) herunterladen und konfigurieren. Gehen Sie dazu so vor:

Rufen Sie in der Google Cloud Console die Seite Workload Identity-Pools auf.
Zu Workload Identity-Pools
Wählen Sie in der Tabelle den Pool aus, um die Detailseite des Pools aufzurufen.
Klicken Sie auf Zugriff erlauben.
Wählen Sie Zugriff mit föderierten Identitäten gewähren (empfohlen) aus.
So laden Sie die Standardanmeldedaten für Anwendungen (ADC) herunter, damit Ihre Arbeitslast auf Clientbibliotheken zugreifen kann:
1. Klicken Sie auf Konfiguration herunterladen.
2. Führen Sie im Dialogfeld Anwendung konfigurieren die folgenden Schritte aus:
  1. Wählen Sie in der Drop-down-Liste Anbieter Ihren Anbieter aus.
  2. Geben Sie unter OIDC-Tokenpfad oder SAML-Assertion-Pfad den Pfad ein, in dem sich das Token oder die Assertion befindet.
3. Klicken Sie auf Konfiguration herunterladen und notieren Sie sich den Pfad, unter dem Sie die Datei gespeichert haben.

Anmeldedaten-Konfiguration erstellen

Die Cloud-Clientbibliotheken, die gcloud CLI und Terraform können automatisch externe Anmeldedaten abrufen und mit diesen auf Google Cloud zugreifen. 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, wenn Sie die Identitätsübernahme des Dienstkontos verwenden

Die Cloud-Clientbibliotheken erhalten externe Anmeldedaten aus einer lokalen Datei, eine HTTP-URL. Dazu starten sie eine lokale ausführbare Datei:

Ausführbare Anmeldedaten: Die Bibliotheken starten eine ausführbare Datei, wenn sie neue Anmeldedaten benötigen. Wenn die ausführbare Datei erfolgreich neue Anmeldedaten abruft, muss sie ein JSON-Dokument in STDOUT schreiben, das in etwa so aussieht:
OIDC
```
{
  "version": 1,
  "success": true,
  "token_type": "urn:ietf:params:oauth:token-type:id_token",
  "id_token": "HEADER.PAYLOAD.SIGNATURE",
  "expiration_time": 1620499962
}
```
Wenn die ausführbare Datei keine neuen Anmeldedaten abruft, muss sie ein JSON-Dokument in STDOUT schreiben, das in etwa so aussieht:
```
{
  "version": 1,
  "success": false,
  "code": "401",
  "message": "Caller not authorized."
}
```
Die JSON-Dokumente verwenden die folgenden Felder:
- version: Die Version der JSON-Ausgabe. Nur Version 1 wird unterstützt.
- success: Der Status der Antwort.
  
  Bei true muss die Antwort die Felder id_token und token_type enthalten. Die ausführbare Datei muss mit dem Exit-Code 0 beendet werden.
  
  Bei false muss die Antwort die Felder code und message enthalten und mit einem Wert ungleich Null beendet werden.
- token_type: Der Tokentyp der externen Anmeldedaten. Unterstützte Werte sind:
  - urn:ietf:params:oauth:token-type:id_token
  - urn:ietf:params:oauth:token-type:jwt
- id_token: Die externen Anmeldedaten.
- expiration_time: Die Ablaufzeit des OIDC-Tokens in Sekunden (Unixzeit). Dieses Feld ist nur erforderlich, wenn in der Konfiguration der Anmeldedaten eine Ausgabedatei angegeben wurde.
- code: der Fehlercodestring.
- message: die Fehlermeldung
SAML
```
{
  "version": 1,
  "success": true,
  "token_type": "urn:ietf:params:oauth:token-type:saml2",
  "saml_response": "...",
  "expiration_time": 1620499962
}
```
Wenn die ausführbare Datei keine neuen Anmeldedaten abruft, muss sie ein JSON-Dokument in STDOUT schreiben, das in etwa so aussieht:
```
{
  "version": 1,
  "success": false,
  "code": "401",
  "message": "Caller not authorized."
}
```
Die JSON-Dokumente verwenden die folgenden Felder:
- version: Die Version der JSON-Ausgabe. Nur Version 1 wird unterstützt.
- success: Der Status der Antwort.
  
  Bei true muss die Antwort die Felder id_token und token_type enthalten. Die ausführbare Datei muss mit dem Exit-Code 0 beendet werden.
  
  Bei false muss die Antwort die Felder code und message enthalten und mit einem Wert ungleich Null beendet werden.
- token_type: Der Tokentyp der externen Anmeldedaten. Muss urn:ietf:params:oauth:token-type:saml2 lauten.
- saml_response: die SAML-Antwort oder die base64-codierte SAML-Assertion.
- expiration_time: Die Ablaufzeit der Assertion in Sekunden (Unixzeit). Dieses Feld ist nur erforderlich, wenn in der Konfiguration der Anmeldedaten eine Ausgabedatei angegeben wurde.
- code: der Fehlercodestring.
- message: die Fehlermeldung
Beim Starten der ausführbaren Datei legen Clientbibliotheken folgende Umgebungsvariablen fest:
- GOOGLE_EXTERNAL_ACCOUNT_AUDIENCE: Zielgruppe aus der Konfiguration der Anmeldedaten. Immer vorhanden.
- GOOGLE_EXTERNAL_ACCOUNT_TOKEN_TYPE: Erwarteter Tokentyp des Subjekts. Immer vorhanden.
- GOOGLE_EXTERNAL_ACCOUNT_IMPERSONATED_EMAIL: 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.
Wenn Sie ausführbare Datei-basierte Anmeldedaten verwenden möchten, müssen Sie die Umgebungsvariable GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES auf 1 setzen.
Dateibasierte Anmeldedaten: Die Bibliotheken lesen die externen Anmeldedaten aus einer lokalen Nur-Text- oder JSON-Datei aus. Beispiele:
JSON
```
{
  "mytoken": "ey...
}
```
Text
```
ey...
```
Die externen Anmeldedaten können Folgendes sein:
- Ein OIDC-Token
- eine SAML-Antwort
- eine base64-codierte SAML-Assertion
Sie müssen die Datei regelmäßig aktualisieren, damit sie immer gültige Anmeldedaten enthält. Beispiel: Wenn das OIDC-Token oder die SAML-Assertion eine Stunde lang gültig ist, müssen Sie die Datei mindestens einmal pro Stunde aktualisieren.
URL-basierte Anmeldedaten: Die Bibliotheken führen immer dann eine GET-Anfrage an einen HTTP-Endpunkt aus, wenn sie neue Anmeldedaten benötigen. Der Endpunkt muss eine Nur-Text- oder JSON-Antwort zurückgeben, die dem Format entspricht, das von den dateibasierten Anmeldedaten verwendet wird.

So erstellen Sie eine Konfigurationsdatei für Anmeldedaten:

Ausführbare Datei-basierte Anmeldedaten

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

PROJECT_NUMBER: die Projektnummer des Projekts, das den Workload Identity-Pool enthält.
POOL_ID: die ID des Workload Identity-Pools.
PROVIDER_ID: die ID des Workload Identity-Poolanbieters.
SERVICE_ACCOUNT_EMAIL: Wenn Sie die Identitätsübernahme des Dienstkontos verwenden, ersetzen Sie dies durch die E-Mail-Adresse des Dienstkontos. Lassen Sie dieses Flag weg, wenn Sie keine Identitätsübernahme des Dienstkontos verwenden.
SERVICE_ACCOUNT_TOKEN_LIFETIME: Wenn Sie die Identitätsübernahme für ein Dienstkonto verwenden, ersetzen Sie dies durch die Lebensdauer des Zugriffstokens für das Dienstkonto in Sekunden. Der Standardwert ist eine Stunde, wenn nicht angegeben. Lassen Sie dieses Flag weg, wenn Sie keine Identitätsübernahme des Dienstkontos verwenden. Wenn Sie eine Lebensdauer angeben möchten, die länger als eine Stunde ist, müssen Sie die Einschränkung der Organisationsrichtlinie constraints/iam.allowServiceAccountCredentialLifetimeExtension konfigurieren.
FILEPATH: die Datei, in der die Konfiguration gespeichert werden soll
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: Ein Pfad, der auf die 3PI-Anmeldedaten verweist, 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.

Dateibasierte Anmeldedaten

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

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

URL-basierte Anmeldedaten

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

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

Anmeldedatenkonfiguration für den Zugriff auf Google Cloud verwenden

Gehen Sie so vor, damit Ihre Anmeldedatenkonfiguration von Tools und Clientbibliotheken verwendet werden kann:

Initialisieren Sie eine Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS und verweisen Sie auf die Konfigurationsdatei für Anmeldedaten:
Bash
export GOOGLE_APPLICATION_CREDENTIALS=`pwd`/FILEPATH.json
Dabei ist FILEPATH der relative Pfad zur Konfigurationsdatei für Anmeldedaten.
PowerShell
$env:GOOGLE_APPLICATION_CREDENTIALS = Resolve-Path 'FILEPATH.json'
Dabei ist FILEPATH der relative Pfad zur Konfigurationsdatei für Anmeldedaten.
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.

Nächste Schritte

Weitere Informationen zur Workload Identity-Föderation
Best Practices für die Verwendung der Workload Identity-Föderation
Workload Identity-Pools und -Anbieter verwalten

Workload Identity-Föderation mit anderen Identitätsanbietern konfigurieren

Externen IdP vorbereiten

OIDC

SAML

OIDC

SAML

Identitätsföderation von Arbeitslasten konfigurieren

OIDC-JWKs verwalten (optional)

Anbieter erstellen und OIDC-JWKs hochladen

OIDC-JWKs aktualisieren

Alle hochgeladenen OIDC-JWKs löschen

Attributzuordnung und -bedingung definieren

OIDC

SAML

OIDC

SAML

Workload Identity-Pool und -Anbieter erstellen

Erforderliche Rollen

Console

OIDC

SAML

gcloud

OIDC

SAML

Optional: Verschlüsselte SAML-Assertions von Ihrem IdP akzeptieren

SAML-Assertion-Verschlüsselungsschlüssel für die Workload Identity-Föderation erstellen

SAML 2.0-konformen IdP für die Ausgabe verschlüsselter SAML-Assertions konfigurieren

Verschlüsselungsschlüssel der Workload Identity-Föderation löschen

Unterstützte SAML-Verschlüsselungsalgorithmen

Arbeitslast authentifizieren

Externer Arbeitslast den Zugriff auf Google Cloud-Ressourcen erlauben

Direkter Ressourcenzugriff

Console

Nach Thema

Nach Gruppe

Nach Attribut

gcloud

Nach Thema

Nach Gruppe

Nach Attribut

Identitätsübertragung für ein Dienstkonto

Console

gcloud

Nach Thema

Nach Gruppe

Nach Attribut

Konfiguration von Anmeldedaten herunterladen

Anmeldedaten-Konfiguration erstellen

OIDC

SAML

JSON

Text

Ausführbare Datei-basierte Anmeldedaten

Dateibasierte Anmeldedaten

URL-basierte Anmeldedaten

Anmeldedatenkonfiguration für den Zugriff auf Google Cloud verwenden

Bash

PowerShell

C++

Einfach loslegen (Go)

Java

Node.js

Python

gcloud

Terraform

gsutil

bq

Nächste Schritte