Workload Identity-Föderation mit Active Directory konfigurieren

In diesem Leitfaden wird beschrieben, wie Sie Workload Identity-Föderation so verwenden, dass Arbeitslasten mit Active Directory-Anmeldedaten bei Google Cloud authentifiziert werden.

Wenn Sie Windows Server-Arbeitslasten in einer Active Directory-Umgebung ausführen, haben diese Arbeitslasten möglicherweise Zugriff auf Active Directory-Anmeldedaten. Beispiele:

Ein Windows-Dienst ist möglicherweise für die Anmeldung als Domainnutzer konfiguriert.
Eine IIS-Anwendung kann so konfiguriert werden, dass sie als gruppenverwaltetes Dienstkonto (Group Managed Service Account, gMSA) ausgeführt wird.

Durch die Verwendung der Workload Identity-Föderation in Kombination mit Active Directory Federation Services (AD FS) können Sie für diese Arbeitslasten deren Active Directory-Kerberos-Anmeldedaten gegen kurzlebige Google Cloud-Anmeldedaten austauschen. Arbeitslasten können mit diesen kurzlebigen Anmeldedaten auf Google Cloud APIs zugreifen.

Der Austausch von Active Directory-Anmeldedaten gegen kurzlebige Google Cloud-Anmeldedaten funktioniert durch Verkettung von zwei Tokenaustauschvorgängen:

Eine Arbeitslast verwendet OIDC (OpenID Connect), SAML-POST oder WS-Trust, um ein OIDC-Token oder eine SAML-Assertion von AD FS anzufordern. Zur Authentifizierung bei AD FS verwendet die Arbeitslast die integrierte Windows-Authentifizierung (IWA) und ihre vorhandenen Active Directory-Anmeldedaten.
Die Arbeitslast verwendet dann die Workload Identity-Föderation, um das OIDC-Token oder die SAML-Assertion gegen ein STS-Token (Security Token Service) auszutauschen und optional die Identität eines Google Cloud-Dienstkontos zu übernehmen.

In diesem Dokument erfahren Sie, wie Sie diesen Prozess mit dem Workload Authenticator für Windows so automatisieren, dass keine Änderungen an Ihrer Anwendung erforderlich sind.

AD FS vorbereiten

Sie müssen diese Schritte nur einmal ausführen.

Protokoll auswählen

Die Vorbereitung von AD FS hängt davon ab, welches Protokoll Sie verwenden möchten:

SAML: Sie können zulassen, dass Arbeitslasten SAML oder WS-Trust verwenden, um SAML-Assertions zu erhalten.

Wenn Sie SAML oder WS-Trust verwenden möchten, erstellen Sie eine vertrauende Partei in AD FS und konfigurieren einen Workload Identity-Pool, um Assertions zu vertrauen, die für diese vertrauende Seite ausgegeben werden.

Eine Arbeitslast kann sich mit ihrem Active Directory-Nutzer über die SAML-POST-Bindung oder WS-Trust bei AD FS authentifizieren. AD FS gibt dann eine SAML-Assertion aus, die Informationen zum Active Directory-Nutzer und weitere Informationen wie Gruppenmitgliedschaften enthält.

Für die Verwendung von SAML oder WS-Trust ist AD FS 3.0, AD FS für Windows Server 2016 oder eine neuere Version von AD FS erforderlich.
OIDC: Sie können zulassen, dass Arbeitslasten OIDC zum Abrufen von OIDC-Tokens verwenden.

Zur Verwendung von OIDC erstellen Sie einen OIDC-Client (native Anwendung) und eine OIDC-Ressource (Web API) in AD FS. Anschließend konfigurieren Sie einen Workload Identity-Pool, um Zugriffstokens zu vertrauen, die für die Web API ausgestellt wurden.

Eine Arbeitslast kann ihren Active Directory-Nutzer und den OAuth-client_credentials verwenden, um sich für AD FS zu authentifizieren. AD FS gibt dann ein Zugriffstoken, aber kein ID-Token aus.

Das Zugriffstoken enthält Informationen zur OIDC-Clientanwendung, jedoch keine Informationen zum Active Directory-Nutzer oder zu den Gruppenmitgliedschaften der Arbeitslast.

Da Zugriffstokens keine Informationen zum Active Directory-Nutzer enthalten, ist die Verwendung von OIDC möglicherweise weniger flexibel als die Verwendung von SAML oder WS-Trust.

Für die Verwendung von OIDC ist AD FS für Windows Server 2016 oder eine neuere Version von AD FS erforderlich.

Für die Anmeldung muss Ihr IdP signierte Authentifizierungsinformationen bereitstellen: OIDC-IdPs müssen ein JWT bereitstellen und SAML-IdP-Antworten müssen signiert sein.

Voraussetzungen für IWA

In diesem Abschnitt werden die IWA-Voraussetzungen beschrieben, die erforderlich sind, um diese Anleitung verwenden zu können.

Wenn Sie IWA noch nicht mit AD FS verwendet haben, müssen folgende Voraussetzungen erfüllt sein:

Sie haben AD FS so konfiguriert, dass Windows-Authentifizierung zugelassen wird und der richtigen Diensthauptnamen verwendet wird.
Sie haben den erweiterten Schutz für die Authentifizierung konfiguriert, sodass er mit Ihrer AD FS-Bereitstellung kompatibel ist.

Arbeitslast registrieren

So registrieren Sie Ihre Arbeitslast in AD FS:

OIDC

Damit Arbeitslasten OIDC verwenden können, benötigen Sie zwei Anwendungsregistrierungen in AD FS:

Eine Anwendungsregistrierung vom Typ native Anwendung oder Serveranwendung.
Eine Anwendungsregistrierung vom Typ Web API, die einem Anbieter von Workload Identity-Pool in Google Cloud entspricht.

Clientanwendung registrieren

Erstellen Sie eine Clientanwendung, die die Arbeitslast darstellt. Wenn Sie mehrere Arbeitslasten haben, die Zugriff auf Google Cloud benötigen, müssen Sie möglicherweise mehrere Clientanwendungen erstellen.

So registrieren Sie eine Clientanwendung in AD FS:

Öffnen Sie das AD FS MMC-Snap-in und gehen Sie zu Anwendungsgruppen.
Klicken Sie auf Anwendungsgruppe hinzufügen.
Führen Sie auf der Seite Willkommen folgende Schritte aus:
1. Geben Sie in das Textfeld einen Namen für den Client ein.
2. Wählen Sie Serveranwendung aus.
3. Klicken Sie auf Weiter.
Führen Sie auf der Seite Serveranwendung die folgenden Schritte aus:
1. Geben Sie im Textfeld text-field eine Client-ID und einen Weiterleitungs-URI ein.
  
  Wenn Sie nur den Berechtigungstyp client_credentials verwenden möchten, wird der Weiterleitungs-URI nicht verwendet und Sie können einen URI wie http://localhost/ verwenden.
2. Klicken Sie auf Weiter.
Führen Sie auf der Seite Anmeldedaten konfigurieren die folgenden Schritte aus:
1. Wählen Sie aus, wie sich der Client authentifizieren soll. Wenn Sie IWA verwenden möchten, setzen Sie die Integrierte Windows-Authentifizierung auf aktiviert.
2. Wählen Sie den Domainnutzer aus, für den Ihre Anwendung konfiguriert ist.
3. Klicken Sie auf Weiter.
Prüfen Sie auf der Seite Zusammenfassung die Einstellungen und klicken Sie auf Weiter.
Klicken Sie auf Schließen, um das Dialogfeld zu schließen.

Web API-Anwendung für den Workload Identity-Pool erstellen

Erstellen Sie eine weitere Anwendungsregistrierung vom Typ Web API. Diese Anwendung entspricht dem Anbieter eines Workload Identity-Pools. Sie richten damit eine Vertrauensstellung zu Google Cloud ein.

So erstellen Sie die Anwendung in AD FS:

Öffnen Sie das AD FS MMC-Snap-in und gehen Sie zu Anwendungsgruppen.
Klicken Sie auf Anwendungsgruppe hinzufügen.
Geben Sie auf der Begrüßungsseite einen Namen wie Workload Identity Federation (test environment) ein und wählen Sie Web API aus. Klicken Sie anschließend auf Weiter.
Geben Sie auf der Seite Web API konfigurieren eine Kennung der vertrauenden Seite für die Web API ein.

Anstatt eine benutzerdefinierte Kennung der vertrauenden Seite zu definieren, können Sie den folgenden URI als Kennung der vertrauenden Seite verwenden:
```
https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID/providers/PROVIDER_ID
```
Ersetzen Sie Folgendes:
- PROJECT_NUMBER: Projektnummer des Google Cloud-Projekts, mit dem Sie einen Workload Identity-Pool erstellen.
- WORKLOAD_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 den Anbieter des Workload Identity-Pools später erstellen.
Durch diese Formatierung des URI wird sichergestellt, dass die Kennung der vertrauenden Seite einen Workload Identity-Poolanbieter eindeutig identifiziert.

Sie benötigen die Kennung der vertrauenden Seite später, wenn Sie den Anbieter des Workload Identity-Pools konfigurieren.
Klicken Sie auf Weiter.
Wählen Sie auf der Seite Zugriffssteuerungsrichtlinie anwenden eine entsprechende Zugriffsrichtlinie aus und klicken Sie dann auf Weiter.
Fügen Sie auf der Seite Anwendungsberechtigungen konfigurieren die zuvor erstellte Clientanwendung hinzu. Klicken Sie anschließend auf Weiter.
Prüfen Sie auf der Seite Zusammenfassung die Einstellungen und klicken Sie auf Weiter.
Klicken Sie auf Schließen, um das Dialogfeld zu schließen.

SAML oder WS-Trust

Erstellen Sie eine Vertrauensstellung der vertrauenden Seite in AD FS:

Öffnen Sie das AD FS-MMC-Snap-in.
Rufen Sie Vertrauensstellungen der vertrauenden Seite auf.
Klicken Sie auf Vertrauensstellung der vertrauenden Seite hinzufügen.
Führen Sie auf der Seite Willkommen des Assistenten Vertrauensstellung der vertrauenden Seite hinzufügen die folgenden Schritte aus:
1. Wählen Sie Ansprüche unterstützend aus.
2. Klicken Sie auf Start.
Führen Sie auf der Seite Datenquelle auswählen die folgenden Schritte aus:
1. Wählen Sie Daten über die vertrauende Seite manuell eingeben aus.
2. Klicken Sie auf Weiter.
Führen Sie auf der Seite Anzeigename angeben die folgenden Schritte aus:
1. Geben Sie einen Namen für die Vertrauensstellung ein.
2. Klicken Sie auf Weiter.
Klicken Sie auf der Seite Zertifikat konfigurieren auf Weiter. Workload Identity-Föderation unterstützt zwar verschlüsseltes SAML, wird in diesem Verfahren jedoch nicht beschrieben. Weitere Informationen finden Sie in der Anleitung für die gcloud CLI unter Workload Identity-Pool und -Anbieter erstellen weiter unten in dieser Anleitung.
Führen Sie auf der Seite URL konfigurieren folgende Schritte aus:
SAML
Verwenden Sie die folgenden Einstellungen:
- Setzen Sie Unterstützung für das SAML 2.0-WebSSO-Protokoll aktivieren auf Aktiviert.
- Geben Sie im Feld URL des SAML 2.0-Diensts für einmaliges Anmelden der vertrauenden Seite die folgende URL ein:
```
https://sts.googleapis.com/v1/token
```
WS-Trust
Behalten Sie die Standardeinstellungen bei.
Klicken Sie auf Weiter.
Geben Sie auf der Seite IDs konfigurieren die ID einer vertrauenden Seite ein.

Anstatt eine benutzerdefinierte Kennung der vertrauenden Seite zu definieren, können Sie den folgenden URI als Kennung der vertrauenden Seite verwenden:
```
https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID/providers/PROVIDER_ID
```
Ersetzen Sie Folgendes:
- PROJECT_NUMBER: Projektnummer des Google Cloud-Projekts, mit dem Sie einen Workload Identity-Pool erstellen.
- WORKLOAD_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.
Durch diese Formatierung des URI wird sichergestellt, dass die Kennung der vertrauenden Seite einen Workload Identity-Poolanbieter eindeutig identifiziert.

Sie benötigen die Kennung der vertrauenden Seite später, wenn Sie den Anbieter des Workload Identity-Pools konfigurieren.
Klicken Sie auf Weiter.
Wählen Sie auf der Seite Zugriffssteuerungsrichtlinie auswählen die entsprechende Zugriffssteuerungsrichtlinie aus und klicken Sie auf Weiter.
Prüfen Sie auf der Seite Bereit zum Hinzufügen der Vertrauensstellung die Einstellungen und klicken Sie auf Weiter.
Klicken Sie auf der Seite Fertigstellen auf Schließen, um das Dialogfeld zu schließen.

Um mit der Workload Identity-Föderation kompatibel zu sein, müssen SAML-Assertions mindestens einen Anspruch enthalten, der den Active Directory-Nutzer eindeutig identifiziert. In der Regel verwenden Sie zu diesem Zweck die Anforderung Name-ID, die dem Wert des Elements NameID in der SAML-Assertion entspricht.

Zum Anpassen der Anforderungen der SAML-Assertion müssen Sie die Richtlinie zum Ausstellen der Vertrauensstellung der vertrauenden Seite bearbeiten. So bearbeiten Sie die Richtlinie für die Anspruchsausstellung:

Wählen Sie in der Liste der Vertrauensstellungen der vertrauenden Seite die soeben erstellte Vertrauensstellung aus und klicken Sie auf Richtlinie für Anspruchsausstellung bearbeiten.
Klicken Sie auf Regel hinzufügen.
Führen Sie auf der Seite Regeltyp auswählen des Assistenten zum Hinzufügen einer Transformationsanspruchsregel die folgenden Schritte aus:
1. Wählen Sie Eingehenden Anspruch transformieren aus.
2. Klicken Sie auf Weiter.
Konfigurieren Sie auf der Seite Anspruchsregel konfigurieren die folgenden Einstellungen:
- Name der Anspruchsregel: Name Identifier.
- Typ des eingehenden Anspruchs: Wählen Sie Primäre SID, UPN oder einen anderen Anspruch aus, um das Thema eindeutig zu identifizieren.
- Typ des ausgehenden Anspruchs: Namen-ID.
- Format der ausgehenden Namen-ID: Nicht angegeben.
Wählen Sie Alle Anspruchswerte übergeben aus und klicken Sie auf Fertigstellen.
Konfigurieren Sie optional zusätzliche Regeln, um weitere Attribute in die SAML-Assertions aufzunehmen.
Klicken Sie auf OK, um das Dialogfeld für die Anspruchsausstellungsrichtlinie zu schließen.

Identitätsföderation von Arbeitslasten konfigurieren

Sie müssen diese Schritte nur einmal pro Azure AD-Mandanten oder AWS-Konto ausführen, mit dem Sie eine Föderation durchführen möchten. 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

Attributzuordnung und -bedingung definieren

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

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

OIDC

Ihre Attributzuordnungen können die in AD FS-Zugriffstokens eingebetteten Anforderungen als Quellattribute verwenden.

Sie können die folgende Attributzuordnung verwenden, um eine Anwendung zu authentifizieren:

google.subject=assertion.appid

Durch diese Zuordnung wird google.subject auf den Wert der Anforderung appid gesetzt, die die Client-ID der AD FS-Anwendung enthält.

SAML oder WS-Trust

Für Ihre Attributzuordnungen können die in der von AD FS ausgegebenen Assertion verwendet werden. Dies wird weiter oben in diesem Leitfaden beschrieben.

Verwenden Sie die folgende Zuordnung, damit die Workload Identity-Föderation den Anspruch Namen-ID aus der SAML-Assertion verwenden kann, um den Nutzer eindeutig zu identifizieren:

google.subject=assertion.subject

Wenn Sie Ihre Anspruchsausstellungsrichtlinie so konfiguriert haben, dass zusätzliche Ansprüche in SAML-Assertions eingeschlossen werden, können Sie zusätzliche Zuordnungen hinzufügen. Beispiele:

google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid']
attribute.userip=['http://schemas.microsoft.com/2014/09/requestcontext/claims/userip'][0]

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 Clients die Workload Identity-Föderation verwenden können, um kurzlebige Google Cloud-Tokens abzurufen.

Beispiel: Die folgende Bedingung definiert, dass Anwendungen IWA zur Authentifizierung bei AD FS verwenden müssen:

assertion.authmethod=='http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows'

Definieren Sie keine Attributbedingungen, um die Liste der Anwendungen zu steuern, die kurzlebige Anmeldedaten für Google Cloud abrufen können. Verwenden Sie stattdessen Clientberechtigungen in AD FS, um zu definieren, welche Anwendungen zulässig sind.

SAML oder WS-Trust

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

Die folgende Bedingung lässt beispielsweise nur SAML-Assertions zu, die einen bestimmten Anspruch der Gruppenmitgliedschaft enthalten:

"S-1-5-6" in google.groups

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.

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.
Anbietereinstellungen konfigurieren:
OIDC
- Anbieter auswählen: OpenID Connect (OIDC).
- Providername: der Name des Anbieters. Der Name wird auch als Anbieter-ID verwendet. Sie können die Anbieter-ID später nicht mehr ändern.
- Aussteller-URL: https://ADFS_DOMAIN/adfs, wobei ADFS_DOMAIN der Name der öffentlichen Domain des AD FS-Servers oder der Farm ist.
SAML
Verwenden Sie die Anleitung für die gcloud CLI, um die Workload Identity-Föderation von einem SAML 2.0-kompatiblen IdP zu konfigurieren.
Klicken Sie auf Weiter.
Fügen Sie unter Anbieterattribute konfigurieren die zuvor identifizierten Attributzuordnungen hinzu.
Geben Sie unter Attributbedingungen die zuvor identifizierte Attributbedingung ein. Lassen Sie das Feld leer, wenn Sie keine Attributbedingung haben.
Klicken Sie auf Speichern, um den Workload Identity-Pool und -Poolanbieter zu erstellen.

gcloud

Erstellen Sie einen neuen Workload Identity-Pool:
```
gcloud iam workload-identity-pools create WORKLOAD_POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
Ersetzen Sie Folgendes:
- WORKLOAD_POOL_ID: Eindeutige ID für den Pool.
- DISPLAY_NAME: Name des Pools.
- DESCRIPTION: Beschreibung des Pools. Diese Beschreibung wird angezeigt, wenn Zugriff auf Poolidentitäten gewährt wird.
Fügen Sie einen Workload Identity-Poolanbieter hinzu:
OIDC
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="WORKLOAD_POOL_ID" \
    --issuer-uri="https://ADFS_DOMAIN/adfs" \
    --allowed-audiences="RELYING_PARTY_ID" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Ersetzen Sie Folgendes:
- PROVIDER_ID: eine eindeutige ID für den Anbieter.
- WORKLOAD_POOL_ID: die ID des Pools.
- ADFS_DOMAIN: der öffentliche Domainname des AD FS-Servers oder der Farm.
- RELYING_PARTY_ID: die Kennung der vertrauenden Seite der Web API-Anwendung für den Workload Identity-Pool in AD FS. Sie benötigen diesen Parameter nur, wenn Sie eine benutzerdefinierte Kennung der vertrauenswürdigen Partei verwenden.
- MAPPINGS: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben.
- CONDITIONS: Zuvor identifizierte Attributbedingung. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
Das Präfix gcp- ist reserviert und kann nicht in einem Pool oder einer Anbieter-ID verwendet werden.
SAML oder WS-Trust
```
curl -O https://ADFS_DOMAIN/federationmetadata/2007-06/federationmetadata.xml

gcloud iam workload-identity-pools providers create-saml PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --idp-metadata-path="federationmetadata.xml" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Ersetzen Sie Folgendes:
- PROVIDER_ID: eine eindeutige ID für den Anbieter.
- ADFS_DOMAIN: der Domainname Ihres AD FS-Servers oder Ihrer Serverfarm.
- WORKLOAD_POOL_ID: die ID des Pools.
- MAPPINGS: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert 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.

Beispiel:
```
gcloud iam workload-identity-pools providers create-saml example-provider \
    --location="global" \
    --workload-identity-pool="pool-1" \
    --idp-metadata-path="federationmetadata.xml" \
    --attribute-mapping=google.subject=assertion.subject"
```
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
1. Verschieben Sie die Zertifikatsdatei auf Ihren AD FS-Server.
2. Klicken Sie auf Ihrem AD FS-Server mit der rechten Maustaste auf die Schaltfläche Starten (oder drücken Sie Win + X) und klicken Sie auf Windows PowerShell (Administrator).
3. Führen Sie in PowerShell den folgenden Befehl aus, um die Verschlüsselung zu aktivieren:
```
        Set-AdfsRelyingPartyTrust `
        -TargetName NAME `
        -SamlResponseSignature MessageAndAssertion `
        -EncryptionCertificate PATH `
        -EncryptClaims $True
    
```
  Ersetzen Sie Folgendes:
  - NAME: der Name der Vertrauensstellung der vertrauenden Seite
  - PATH: der Pfad der Zertifikatsdatei.
WS-Trust-Nutzer: Diese Funktion ist nur verfügbar, wenn Sie SAML verwenden.

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 pro Arbeitslast ausführen.

Externer Arbeitslast den Zugriff auf Google Cloud-Ressourcen erlauben

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

Direkter Ressourcenzugriff

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

Console

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

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 Subjekt, 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 Rollen zuweisen, die IAM-Zulassungsrichtlinien unterstützt.

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 -subAnforderung in Tokens fest, die von Ihrem externen Identitätsanbieter ausgestellt wurden.
  6. Klicken Sie zum Speichern der Konfiguration auf Speichern und dann auf Schließen.
gcloud

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

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

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

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

Anmeldedaten-Konfiguration erstellen

Sie können zulassen, dass Cloud-Clientbibliotheken und Tools wie die gcloud-Kommandozeile und Terraform die Active Directory-Anmeldedaten verwenden, um sich mithilfe von Workload Authenticator für Windows bei Google Cloud zu authentifizieren.

Workload Authenticator für Windows ist ein Open Source-Tool, das als Plug-in für die Cloud-Clientbibliotheken und Tools wie die gcloud CLI fungiert:

Wenn das Tool oder die Bibliothek neue Anmeldedaten benötigt, startet es den Workload Authenticator im Hintergrund.
Workload Authenticator verwendet OIDC, SAML oder WS-Trust, um ein neues Token oder eine SAML-Assertion von AD FS abzurufen und an das Tool oder die Bibliothek zurückzugeben.
Das Tool oder die Bibliothek tauscht dann mithilfe der Workload Identity-Föderation das Token oder die SAML-Assertion gegen kurzlebige Google Cloud-Anmeldedaten aus.

Wenn Sie den Workload Authenticator für Windows verwenden möchten, müssen Sie eine Konfigurationsdatei für Anmeldedaten erstellen. Die Datei definiert Folgendes:

Wo Workload Authenticator für Windows (wwauth.exe) zu finden ist und mit welchen Parametern die Exe-Datei ausgeführt werden soll.
Welcher Workload Identity-Pool und -Anbieter verwendet werden.
Welches Dienstkonto übernommen wird

So erstellen Sie eine Konfigurationsdatei für Anmeldedaten auf dem Windows Server, auf dem Ihre Arbeitslast ausgeführt wird:

Klicken Sie mit der rechten Maustaste auf Start (oder drücken Sie Win + X) und klicken Sie anschließend auf Windows PowerShell.
Laden Sie die Datei Workload Authenticator für Windows herunter und speichern Sie sie an einem Speicherort, auf den Ihre Arbeitslast zugreifen kann:
```
(New-Object Net.WebClient).DownloadFile(
  "https://github.com/GoogleCloudPlatform/iam-windows-authenticator/releases/latest/download/wwauth.exe",
  "${env:ProgramData}\wwauth.exe")
```
Wenn Sie mit Workload Authenticator für Windows eine Konfigurationsdatei für Anmeldedaten erstellen, enthält die Datei den Pfad zur ausführbaren Datei. Wenn Sie die ausführbare Datei später löschen oder verschieben, können Arbeitslasten die ausführbare Datei nicht mehr finden und verwenden.
Starten Sie wwauth.exe:
```
& ${env:ProgramData}\wwauth.exe
```
Ein Konfigurationsdialogfeld wird geöffnet:
Wählen Sie den Tab AD FS aus und geben Sie die folgenden Einstellungen ein:
- Aussteller-URI des AD FS-Servers: Öffentlicher URI Ihres AD FS-Servers oder Ihrer Farm.
```
https://ADFS_DOMAIN/adfs/
```
  Ersetzen Sie ADFS_DOMAIN durch den öffentlichen Domainnamen Ihres AD FS-Servers oder Ihrer Serverfarm.
Die nächsten Einstellungen hängen vom Protokoll ab, das Sie verwenden möchten:
OIDC
- Protokoll: AdfsOidc.
- ID der vertrauenden Seite: Behalten Sie die Standardeinstellung bei.
- Client-ID: Client-ID (Client-ID) der Serveranwendung in AD FS.
SAML
- Protokoll: AdfsSamlPost.
- Assertion Consumer Service URL: https://sts.googleapis.com/v1/token.
- Anfragen mit Zertifikat signieren: deaktiviert.
WS-Trust
- Protokoll: AdfsWsTrust.
Wählen Sie den Tab Workload Identity aus und geben Sie die folgenden Einstellungen ein:
- Projektnummer: Projektnummer des Projekts, das den Workload Identity-Pool enthält.
- Pool ID: ID des Workload Identity-Pools.
- Anbieter-ID: ID des Workload Identity-Poolanbieters.
- Identitätsübernahme des Dienstkontos: aktiviert, wenn Sie die Identitätsübernahme des Dienstkontos verwenden.
- E-Mail-Adresse: E-Mail-Adresse des Dienstkontos, wenn Sie die Identitätsübernahme des Dienstkontos verwenden.
Wählen Sie den Tab AD FS aus und prüfen Sie, ob das Feld Vertrauensstellungs-ID die URL Ihres Workload Identity-Poolanbieters enthält.
Klicken Sie auf Übernehmen und wählen Sie einen Speicherort für die Datei aus, in der die Konfigurationsdatei für Anmeldedaten gespeichert werden soll.

Im Gegensatz zu einem Dienstkontoschlüssel enthält eine Konfigurationsdatei für Anmeldedaten keine Secrets und muss nicht vertraulich behandelt werden. Details zur Konfigurationsdatei für Anmeldedaten finden Sie unter https://google.aip.dev/auth/4117.

Jetzt können Sie Ihre Konfiguration testen:

Wählen Sie einen Active Directory-Nutzer aus, mit dem Sie testen möchten. Dies kann der Active Directory-Nutzer der Arbeitslast oder der Nutzer sein, mit dem Sie derzeit angemeldet sind.
Klicken Sie auf Testen, um die Konfiguration mit Ihrem aktuellen Nutzer zu testen.

Wählen Sie zum Testen mit einem anderen Nutzer Test > Konfiguration als Nutzer testen aus und geben Sie die Anmeldedaten für den Nutzer ein.

Das Tool versucht jetzt, sich bei Google Cloud zu authentifizieren, indem es die folgenden Schritte ausführt:
1. OIDC-Token oder eine SAML-Assertion von AD FS abrufen.
2. Google Security Token Service-Token abrufen.
3. Nehmen Sie die Identität des Dienstkontos an, wenn Sie die Identitätsübernahme des Dienstkontos verwenden.
Wenn die Authentifizierung erfolgreich ist, wird die Meldung Test erfolgreich abgeschlossen angezeigt:

Anmeldedatenkonfiguration für den Zugriff auf Google Cloud verwenden

Damit Tools und Clientbibliotheken Ihre Anmeldedatenkonfiguration verwenden können, führen Sie die folgenden Schritte auf dem Windows Server aus, auf dem Ihre Arbeitslast ausgeführt wird:

Klicken Sie mit der rechten Maustaste auf Start und dann auf Ausführen.
Geben Sie sysdm.cpl ein und klicken Sie auf OK.
Klicken Sie auf dem Tab Erweitert auf Umgebungsvariablen.
Fügen Sie im Bereich Systemvariablen zwei neue Variablen hinzu:

Name Wert

GOOGLE_APPLICATION_CREDENTIALS Pfad zur Konfigurationsdatei für Anmeldedaten

GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES 1
Klicken Sie auf OK.
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.

Name	Wert
`GOOGLE_APPLICATION_CREDENTIALS`	Pfad zur Konfigurationsdatei für Anmeldedaten
`GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES`	`1`

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 Active Directory konfigurieren

AD FS vorbereiten

Protokoll auswählen

Voraussetzungen für IWA

Arbeitslast registrieren

OIDC

SAML oder WS-Trust

SAML

WS-Trust

Identitätsföderation von Arbeitslasten konfigurieren

Attributzuordnung und -bedingung definieren

OIDC

SAML oder WS-Trust

OIDC

SAML oder WS-Trust

Workload Identity-Pool und -Anbieter erstellen

Erforderliche Rollen

Console

OIDC

SAML

gcloud

OIDC

SAML oder WS-Trust

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

Anmeldedaten-Konfiguration erstellen

OIDC

SAML

WS-Trust

Anmeldedatenkonfiguration für den Zugriff auf Google Cloud verwenden

C++

Einfach loslegen (Go)

Java

Node.js

Python

gcloud

Terraform

gsutil

bq

Nächste Schritte