Workload Identity-Föderation konfigurieren

In diesem Leitfaden wird beschrieben, wie Sie die Anmeldedaten eines externen Identitätsanbieters verwenden, um die Identität eines Dienstkontos zu übernehmen und auf Ressourcen in Google Cloud zuzugreifen. Dieser Vorgang wird als Workload Identity-Föderation bezeichnet.

Gängige Anwendungsfälle für die Workload Identity-Föderation:

  • Hintergrundanwendung oder CI/CD-Pipeline (Continuous Integration/Continuous Delivery) aktivieren, die außerhalb von Google Cloud ausgeführt wird, um auf Google Cloud-Ressourcen und APIs zuzugreifen
  • Nutzern einer Webanwendung, die außerhalb von Google Cloud ausgeführt wird, Zugriff auf Daten gewähren, die in einem Google Cloud-Dienst wie Cloud Storage oder BigQuery gespeichert sind

Für die Verwendung der Workload Identity-Föderation konfigurieren Sie Google Cloud so, dass einem externen Identitätsanbieter wie Amazon Web Services (AWS), Azure Active Directory (AD), einem OIDC-kompatiblen Identitätsanbieter oder einem SAML 2.0-kompatiblen Identitätsanbieter Vorschau vertraut wird. Anwendungen können dann Anmeldedaten verwenden, die vom externen Identitätsanbieter ausgestellt wurden, um die Identität eines Dienstkontos zu übernehmen. Gehen Sie dazu so vor:

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

Mithilfe der Workload Identity-Föderation können Sie vermeiden, dass Dienstkontoschlüssel gespeichert und verwaltet werden müssen.

Hinweis

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

    Aktivieren Sie die APIs

  • Sie benötigen die Rollen "Workload Identity-Pooladministrator" (roles/iam.workloadIdentityPoolAdmin) und "Dienstkontoadministrator" (roles/iam.serviceAccountAdmin) für das Projekt.

    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.

  • Zusätzliche anbieterspezifische Anleitungen:

    SAML

    Wenn Sie die Föderation mit einem SAML 2.0-kompatiblen Identitätsanbieter konfigurieren möchten, müssen Sie außerdem die nachfolgenden Schritte ausführen.

    • Bestimmen Sie, welches Projekt Sie beim Konfigurieren der Workload Identity-Föderation verwenden.

    • Bitten Sie Ihr Account-Management-Team von Google Cloud, den Zugriff auf die SAML 2.0-Vorschau für Ihr Projekt anzufordern. Ihr Account-Management-Team von Google wird Sie benachrichtigen, wenn Ihnen Zugriff auf die Vorschau gewährt wurde.

    • Sie müssen das gcloud-Tool verwenden, um die Workload Identity-Föderation über einen SAML 2.0-Identitätsanbieter zu konfigurieren. Konfigurieren Sie billing/quota_project für das Projekt, dem Zugriff auf die SAML-Vorschau gewährt wurde.

Externen Identitätsanbieter vorbereiten

Wenn Sie Workload Identity-Föderation verwenden möchten, müssen Sie in Ihrem Projekt einen Workload Identity-Pool und einen Workload Identity-Pool-Anbieter konfigurieren:

AWS

AWS-Nutzer und AWS-Rollen können permanente oder temporäre AWS-Sicherheitsanmeldedaten verwenden, um die Identität eines Dienstkontos in Google Cloud zu übernehmen.

Damit AWS-Sicherheitsanmeldedaten verwendet werden können, müssen Sie den Workload Identity-Pool so konfigurieren, dass er Ihrem AWS-Konto vertraut. Tokens für Sicherheitsanmeldedaten, die für dieses AWS-Konto ausgestellt werden, werden dann von der Workload Identity-Föderation erkannt. Sie können die Tokens verwenden, um kurzlebige Anmeldedaten für das Dienstkonto abzurufen.

Azure

Azure-Nutzer und Diensthauptkonten können Azure AD-Zugriffstokens verwenden, um die Identität eines Dienstkontos in Google Cloud zu übernehmen.

Um die Verwendung von Azure AD-Zugriffstokens zu ermöglichen, müssen Sie den Workload Identity-Pool so konfigurieren, dass er einer Azure AD-Anwendung vertraut. Für diese Anwendung ausgegebene Zugriffstokens werden dann von der Workload Identity-Föderation erkannt und Sie können die Tokens verwenden, um kurzlebige Anmeldedaten für das Dienstkonto abzurufen.

Als Best Practice sollten Sie eine neue Anwendung in Azure AD erstellen und die Anwendung nur zum Abrufen von Google Cloud-Anmeldedaten verwenden:

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

  2. Legen Sie einen Anwendungs-ID-URI für die Anwendung fest.

    Anstatt einen benutzerdefinierten Anwendungs-ID-URI zu definieren, können Sie den folgenden URI verwenden:

    https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

    Ersetzen Sie die folgenden Werte:

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

    Dieses Format sorgt dafür, dass der Anwendungs-ID-URI den Anbieter eines Workload Identity-Pools eindeutig identifiziert.

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

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

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

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

GitHub Actions

Sie können zulassen, dass ein GitHub Actions-Workflow ein GitHub-OIDC-Token verwendet, um die Identität eines Dienstkontos in Google Cloud zu übernehmen.

Damit diese Tokens verwendet werden können, müssen Sie den Workload Identity-Pool so konfigurieren, dass er vertrauenswürdigen OIDC-Tokens von GitHub vertraut. Für Workflows ausgestellte ID-Tokens werden dann von der Workload Identity-Föderation erkannt und Sie können mit den Tokens kurzlebige Anmeldedaten für das Dienstkonto abrufen.

OIDC

Sie können Nutzern und Anwendungen erlauben, die Identität eines Dienstkontos in Google Cloud zu übernehmen. Dazu verwenden Sie ID-Tokens oder ein JSON Web Token-formatiertes Zugriffstoken, das von einem OIDC-kompatiblen Identitätsanbieter ausgestellt wurde.

Damit Sie diese Tokens verwenden können, müssen Sie den Workload Identity-Pool so konfigurieren, dass er Ihrem externen Identitätsanbieter vertraut. Vom externen Identitätsanbieter ausgestellte Tokens werden dann von der Workload Identity-Föderation erkannt und Sie können mit den Tokens kurzlebige Anmeldedaten für das Dienstkonto abrufen.

Wenn Sie die Workload Identity-Föderation verwenden möchten, muss der OIDC-Metadaten-URI Ihres Identitätsanbieters über das Internet öffentlich zugänglich sein und den Endpunkt ISSUER/.well-known/openid-configuration verwenden. Dabei ist ISSUER die Aussteller-URL, die Ihren Anbieter eindeutig identifiziert. Google fragt den Metadatenendpunkt ab, um den JSON Web Key Set (JWKS) Ihres Anbieters abzurufen, und verwendet diesen Schlüsselsatz dann zum Validieren von Tokens.

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, konfigurieren Sie eine dedizierte Anwendung oder Ressource in Ihrem Identitätsanbieter ausschließlich zum Abrufen von Google Cloud-Anmeldedaten.

SAML

Sie können zulassen, dass Nutzer und Anwendungen ein Dienstkonto in Google Cloud übernehmen, indem Sie Assertions verwenden, die von einem SAML 2.0-konformen Identitätsanbieter ausgestellt wurden. Föderation mit verschlüsselten Assertions wird nicht unterstützt.

Konfigurieren Sie Ihren SAML-Identitätsanbieter so, dass Assertions mit dem Anbieter des Workload Identity-Pools als Zielgruppe im Format https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID ausgegeben werden.

Um die Verwendung von Assertions zu ermöglichen, müssen Sie den Workload Identity-Pool so konfigurieren, dass er Ihrem externen Identitätsanbieter vertraut. Dazu stellen Sie ihm das Metadaten-Dokument Ihres SAML-Identitätsanbieters zur Verfügung.

Die Workload Identity-Föderation erkennt dann Assertions, die vom externen Identitätsanbieter ausgegeben wurden. Sie können die Tokens verwenden, um kurzlebige Anmeldedaten für Dienstkonten abzurufen.

Föderation konfigurieren

So stellen Sie eine Verbindung mit Ihrem externen Identitätsanbieter her:

  1. Bereiten Sie ein Google Cloud-Projekt vor, das den Workload Identity-Pool und -Anbieter enthält.
  2. Definieren Sie eine Attributzuordnung und eine optionale Attributbedingung, mit denen die Anmeldedaten des Identitätsanbieters externen Identitäten zugeordnet werden.
  3. Workload Identity-Pool und Anbieter erstellen.

Dieser Prozess wird in den folgenden Abschnitten beschrieben.

Projekt vorbereiten

Wählen Sie das Projekt aus, das den Workload Identity-Pool enthalten soll, und bereiten Sie es vor:

  1. Sie benötigen die Rollen "Workload Identity-Pooladministrator" (roles/iam.workloadIdentityPoolAdmin) und "Dienstkontoadministrator" (roles/iam.serviceAccountAdmin) für das Projekt.

    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.

  2. Aktualisieren Sie die Organisationsrichtlinie für Ihre Organisation, um die Föderation zuzulassen.

  3. IAM, Resource Manager, Service Account Credentials, and Security Token Service (STS) APIs aktivieren.

    Aktivieren Sie die APIs

Attributzuordnung und -bedingung definieren

Definieren Sie eine Attributzuordnung und eine optionale Attributbedingung, mit denen die Anmeldedaten des Identitätsanbieters externen Identitäten zugeordnet werden.

Die von Ihrem externen Identitätsanbieter ausgestellten Anmeldedaten enthalten ein oder mehrere Attribute, die auch als Anforderungen bezeichnet werden. Die Workload Identity-Föderation bezeichnet diese Attribute als Assertion-Attribute und stellt ihnen assertion. voran.

Mit einer Attributzuordnung können Sie Assertion-Attribute den vordefinierten Zielattributen zuordnen, die von der Workload Identity-Föderation erkannt werden. Diese vordefinierten Zielattribute sind:

Attribut Beschreibung
google.subject Erforderlich. Eine eindeutige Kennung für den Nutzer. Dieses Attribut wird in IAM-Rollenbindungen vom Typ principal:// verwendet und in Cloud Logging-Logs angezeigt. Der Wert muss eindeutig sein und darf 127 Zeichen nicht überschreiten.
google.groups Optional. Eine Reihe von Gruppen, zu denen die Identität gehört. Dieses Attribut wird in IAM-Rollenbindungen vom Typ principalSet:// verwendet, um allen Mitgliedern einer Gruppe Zugriff zu gewähren.
attribute.NAME Optional. Sie können bis zu 50 benutzerdefinierte Attribute definieren und diese Attribute in IAM-principalSet://-Rollenbindungen verwenden, um Zugriff auf alle Identitäten mit einem bestimmten Attribut zu gewähren.

Eine Attributzuordnung hat die Form TARGET_ATTRIBUTE=SOURCE_EXPRESSION. Betrachten Sie die folgenden Beispiele:

  • Diese Zuordnung weist das Assertion-Attribut sub google.subject zu:

    google.subject=assertion.sub

  • Diese Zuordnung verwendet einen CEL-Ausdruck (Common Expression Language), um mehrere Assertion-Attribute zu verketten:

    google.subject="myprovider::" + assertion.aud + "::" + assertion.sub

  • Bei dieser Zuordnung wird ein anderer CEL-Ausdruck verwendet, um einem Namen das GUID-wertige Assertion-Attribut workload_id zuzuordnen und das Ergebnis einem benutzerdefinierten Attribut namens attribute.my_display_name zuzuweisen:

    attribute.my_display_name={
  "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
  "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
}[assertion.workload_id]

  • Diese Zuordnung verwendet logische CEL-Operatoren und -Funktionen, um ein benutzerdefiniertes Attribut mit dem Namen attribute.environment je nach Amazon-Ressourcenname (Amazon Resource Name, ARN) der Identität auf prod oder test festzulegen:

    attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"

  • Diese Zuordnung verwendet die Funktion extract, um ein benutzerdefiniertes Attribut aws_role mit dem Namen der angenommenen Rolle oder, falls keine Rolle angenommen wurde, mit dem ARN der Identität zu füllen.

    attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

Optional können Sie auch eine Attributbedingung definieren. 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.

Um die richtigen Attributzuordnungen und Bedingungen für Ihren Anwendungsfall auszuwählen, müssen Sie entscheiden, ob Dienstidentitäten oder Nutzeridentitäten zugeordnet werden sollen:

  • Durch die Zuordnung von Dienstidentitäten können Sie eine Hintergrundanwendung oder eine CI/CD-Pipeline aktivieren, die außerhalb von Google Cloud ausgeführt wird, um kurzlebige Anmeldedaten für Google Cloud abzurufen. Die Anwendung erhält diese kurzlebigen Anmeldedaten in ihrem Namen, ohne dass der Nutzer beteiligt ist.
  • Durch die Zuordnung von Nutzeridentitäten können Sie Nutzern einer Anwendung, die außerhalb von Google Cloud ausgeführt wird, die Möglichkeit geben, kurzlebige Anmeldedaten für Google Cloud abzurufen. Die Anwendung erhält diese kurzlebigen Anmeldedaten im Namen eines Nutzers.

Dienstidentitäten zuordnen

AWS

Ihre Attributzuordnungen können die Antwortfelder für GetCallerIdentity als Quellattribute verwenden. Zu diesen Feldern gehören:

  • account mit der AWS-Kontonummer.
  • arn mit dem AWS-ARN der externen Entität.
  • userid mit der eindeutigen Kennung der aufrufenden Entität.

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

google.subject=assertion.arn
attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

Mit dieser Zuordnung können Sie bestimmten EC2-Instanzen oder nach Rolle die Berechtigung gewähren, die Identität eines Dienstkontos zu übernehmen.

Ihr AWS-Konto kann zwar eine große Anzahl von Nutzern und Rollen enthalten, aber möglicherweise benötigt nur ein kleiner Teil davon Zugriff auf Google Cloud-Ressourcen. Verwenden Sie eine Attributbedingung, um die Anzahl der Nutzer und Rollen zu begrenzen, die Workload Identity-Föderation verwenden können. Die folgende Bedingung ermöglicht beispielsweise einem bestimmten Konto Zugriff auf Google Cloud-Ressourcen:

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

Azure

Ihre Attributzuordnungen können die in Azure-Zugriffstokens eingebetteten Anforderungen, einschließlich benutzerdefinierter Anforderungen, als Quellattribute verwenden.

Zum Abrufen einer vollständigen Liste der Anforderungen, auf die Sie verweisen können, stellen Sie eine Verbindung zu einer Azure-VM her, der eine verwaltete Identität zugewiesen ist. Gehen Sie dann so vor:

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

    Bash

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

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

    PowerShell

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

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

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

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

Sie können die folgende Attributzuordnung verwenden, um sich mit einem Diensthauptkonto zu authentifizieren:

google.subject=assertion.sub

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

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

Definieren Sie keine Attributbedingungen, um zu steuern, welche Identitäten kurzlebige Anmeldedaten für Google Cloud abrufen können. Konfigurieren Sie stattdessen Ihre Azure AD-Anwendung für die Verwendung von Rollenzuweisungen für Anwendungen.

GitHub Actions

Ihre Attributzuordnungen können die im OIDC-Token eingebetteten Anforderungen als Quellattribute verwenden. Dazu gehören:

  • sub: Enthält den Repository-Namen und die Git-Referenz, z. B. repo:username/reponame:ref:refs/heads/master.
  • repository: Enthält den Namen des Inhabers und des Repositorys, z. B. username/reponame.
  • repository_owner: Enthält den Inhaber, der ein Nutzername oder der Name einer GitHub-Organisation sein kann.
  • ref: Enthält die Git-Referenz, z. B. refs/heads/main.

Mit der folgenden Attributzuordnung wird google.subject auf die Anforderung sub aus dem OIDC-Token von GitHub Actions festgelegt. Da die Anforderung sub sowohl den Repository-Namen als auch die Git-Referenz enthält, können Sie über diese Zuordnung den Zugriff nach Repository und Zweig steuern:

google.subject=assertion.sub

Die Steuerung des Zugriffs nach Repository und Zweig kann nützlich sein, wenn bestimmte Zweige (z. B. main) anderen Zugriff auf Ressourcen benötigen als andere Zweige (z. B. Feature-Zweige).

Wenn Sie den Zugriff nicht nach Zweigen unterscheiden möchten, können Sie die folgende Attributzuordnung verwenden, bei der google.subject auf die Anforderung repository festgelegt wird:

google.subject=assertion.repository

Optional können Sie mit einer Attributbedingung zusätzliche Anforderungen definieren, die ID-Tokens erfüllen müssen. Die folgende Bedingung begrenzt beispielsweise den Zugriff auf ID-Tokens für Workflows, die den Git-Branch main verwenden:

assertion.ref=='refs/heads/main'

OIDC

Ihre Attributzuordnungen können die in dem ID-Token oder Zugriffstoken eingebetteten Anforderungen des externen Identitätsanbieters 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 Identitätsanbieter füllen die Anforderung sub mit einer eindeutigen und unveränderlichen ID aus. Erwägen Sie bei diesen Identitätsanbietern die Zuordnung der Anforderung sub zu google.subject:

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.

Ihr Identitätsanbieter kann zwar eine große Anzahl von Nutzern enthalten, aber möglicherweise benötigt nur ein kleiner Teil davon Zugriff auf Google Cloud-Ressourcen. Wenn Sie die Anzahl der Nutzer und Anmeldedaten begrenzen möchten, die Workload Identity-Föderation verwenden können, können Sie optional eine Attributbedingung verwenden.

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

In den Attributzuordnungen können die Elemente <Subject> und <Attribute> verwendet werden, die in die vom externen Identitätsanbieter 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>.

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 Identitätsanbieter füllen die Anforderung NameId mit einer eindeutigen und unveränderlichen ID aus. Erwägen Sie bei diesen Identitätsanbietern die Zuordnung des Attributs NameId zu google.subject:

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.

Ihr Identitätsanbieter kann zwar eine große Anzahl von Nutzern enthalten, aber möglicherweise benötigt nur ein kleiner Teil davon Zugriff auf Google Cloud-Ressourcen. Wenn Sie die Anzahl der Nutzer und Anmeldedaten begrenzen möchten, die Workload Identity-Föderation verwenden können, können Sie optional eine Attributbedingung verwenden.

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://idp.com/SAML/Attributes/AllowGcpFederation'][0]=='true'

Workload Identity-Pool und -Anbieter erstellen

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

Console

  1. Rufen Sie in der Cloud Console die Seite Neuer Arbeitslastanbieter und -anbieterpool auf.

    Zum neuen Arbeitslastanbieter und -anbieterpool

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

  3. Klicken Sie auf Weiter.

  4. Wählen Sie in der Drop-down-Liste Anbieter auswählen Ihren Anbieter aus:

    • AWS, wenn Sie eine Föderation mit AWS ausführen.
    • OpenID Connect (OIDC), wenn Sie einen OIDC-kompatiblen Anbieter wie Microsoft Azure verbinden.
    • Sie können die Workload Identity-Föderation über einen SAML 2.0-Identitätsanbieters nicht mit der Cloud Console konfigurieren. Sie müssen das gcloud-Tool verwenden, um die Workload Identity-Föderation über einen SAML 2.0-Identitätsanbieter zu konfigurieren.

  5. Geben Sie unter Anbieterdetails Details für Ihren Identitätsanbieter ein:

    AWS

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

    Azure

    • Name des Anbieters: Name des Anbieters. Der Name wird auch als Anbieter-ID verwendet. Sie können die Anbieter-ID später nicht mehr ändern.
    • Aussteller-URL: https://sts.windows.net/TENANT_ID, wobei TENANT_ID die Mandanten-ID (GUID) Ihres Azure AD-Mandanten ist.

    GitHub Actions

    • Name des Anbieters: Name des Anbieters. Der Name wird auch als Anbieter-ID verwendet. Sie können die Anbieter-ID später nicht mehr ändern.
    • Aussteller-URL: https://token.actions.githubusercontent.com/

    OIDC

    • Name des Anbieters: Name des Anbieters. Der Name wird auch als Anbieter-ID verwendet. Sie können die Anbieter-ID später nicht mehr ändern.
    • Aussteller-URL: Aussteller-URL Ihres Identitätsanbieters.

  6. Klicken Sie auf Weiter.

  7. Fügen Sie unter Anbieterattribute konfigurieren die zuvor identifizierten Attributzuordnungen hinzu.

  8. Geben Sie unter Attributbedingungen die zuvor identifizierte Attributbedingung ein. Lassen Sie das Feld leer, wenn Sie keine Attributbedingung haben.

  9. Klicken Sie auf Speichern, um den Workload Identity-Pool und -Poolanbieter zu erstellen.

gcloud

  1. Erstellen Sie einen neuen Workload Identity-Pool:

    gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"

    Ersetzen Sie die folgenden Werte:

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

  2. Fügen Sie einen Workload Identity-Pool-Anbieter hinzu:

    AWS 

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

    Ersetzen Sie die folgenden Werte:

    Beispiel:

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

    Azure 

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://sts.windows.net/TENANT_ID" \
    --allowed-audiences="APPLICATION_ID_URI" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"

    Ersetzen Sie die folgenden Werte:

    Beispiel:

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

    GitHub Actions 

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://token.actions.githubusercontent.com/" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"

    Ersetzen Sie die folgenden Werte:

    OIDC 

    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"

    Ersetzen Sie die folgenden Werte:

    SAML 

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

    Beispiel:

    gcloud iam workload-identity-pools providers create-saml example-provider \
    --location="global" \
    --workload-identity-pool="pool-1" \
    --idp-metadata-path="/path/to/idp_metadata.xml" \
    --attribute-mapping="google.subject=assertion.subject,google.groups=assertion.attributes.groups"

    Wenn Sie die folgende Fehlermeldung erhalten:

    INVALID_ARGUMENT: Invalid WorkloadIdentityPoolProvider IDP configuration: PROVIDERCONFIG_NOT_SET.

    Prüfen Sie, ob Sie die auf der Seite Zugriffsanfrage für SAML-Vorschau beschriebenen Schritte ausgeführt haben.

Nächste Schritte