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.

Vorbereitung

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

    Aktivieren Sie die APIs

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-Pooladministrator (roles/iam.workloadIdentityPoolAdmin)
  • Dienstkontoadministrator (roles/iam.serviceAccountAdmin)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

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.

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.

    Wenn Sie den Anwendungs-ID-URI festlegen, wird standardmäßig api://<appid> verwendet. Notieren Sie sich den URI, da Sie ihn später beim Erstellen des Workload Identity-Poolanbieters und der Konfigurationsdatei für Anmeldedaten benötigen.

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, wobei ISSUER der Wert der Anforderung des Ausstellers (iss) im Token ist. 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.

Standardmäßig erwartet die Workload Identity-Föderation Tokens, die die folgende URL als Zielgruppenanforderung (aud) verwenden:

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

Dabei gilt:

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

Sie können beim Erstellen des Workload Identity-Pools und -Anbieters eine benutzerdefinierte Liste zulässiger Zielgruppen angeben.

OIDC (AD FS)

Active Directory-Nutzer können OIDC-Zugriffstokens aus Active Directory Federation Services (AD FS) verwenden, um die Identität eines Dienstkontos in Google Cloud zu übernehmen.

Damit eine Anwendung AD FS-Zugriffstokens anfordern und mit diesen Tokens auf Google Cloud zugreifen kann, benötigen Sie zwei Anwendungsregistrierungen in AD FS:

  1. Eine Anwendungsregistrierung vom Typ native Anwendung oder Serveranwendung.

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

Anschließend konfigurieren Sie einen Workload Identity-Anbieter, um Zugriffstokens zu akzeptieren, die an die Web API ausgegeben werden.

Integrierte Windows-Authentifizierung verwenden

Sie können die Föderation von Workload Identity mit der integrierten Windows-Authentifizierung (IWA) kombinieren. IWA ermöglicht Active Directory-Anwendungen die Authentifizierung bei AD FS mit Kerberos- oder NTLM-Anmeldedaten. Durch die Kombination von Workload Identity-Föderation und IWA vermeiden Sie die Speicherung und Verwaltung von AD FS-Clientanmeldedaten und Dienstkontoschlüsseln.

Wenn Sie IWA verwenden, müssen die folgenden Voraussetzungen erfüllt sein:

Clientanwendung registrieren

So registrieren Sie eine Anwendung in AD FS für Windows Server 2019:

  1. Öffnen Sie das AD FS MMC-Snap-in und gehen Sie zu Anwendungsgruppen.
  2. Klicken Sie auf Anwendungsgruppe hinzufügen.
  3. Geben Sie auf Begrüßungsseite einen Namen für den Client ein und wählen Sie Serveranwendung aus. Klicken Sie anschließend auf Weiter.
  4. Geben Sie auf der Seite Serveranwendung eine Client-ID und einen Weiterleitungs-URI ein. Wenn Sie nur den Grant-Typ client_credentials verwenden möchten, wird der Weiterleitungs-URI nicht verwendet und Sie können einen URI wie http://localhost/ verwenden. Klicken Sie anschließend auf Weiter.
  5. Wählen Sie auf der Seite Anwendungsanmeldedaten konfigurieren aus, wie sich der Client authentifizieren soll. Setzen Sie zur Verwendung von IWA Windows Integrated Authentication auf aktiviert und wählen Sie den Domainnutzer aus, für den Ihre Anwendung ausgeführt werden soll. Klicken Sie anschließend auf Weiter.
  6. Prüfen Sie auf der Seite Zusammenfassung die Einstellungen und klicken Sie auf Weiter.
  7. Klicken Sie auf Schließen, um das Dialogfeld zu schließen.

Web-API-Anwendung für den Workload Identity-Föderationspool erstellen

Erstellen Sie eine weitere Anwendungsregistrierung vom Typ Web API. Diese Anwendung entspricht einem Workload Identity-Poolanbieter. Sie richten damit eine Vertrauensstellung zu Google Cloud ein.

So erstellen Sie die Anwendung in AD FS für Windows Server 2019:

  1. Öffnen Sie das AD FS MMC-Snap-in und gehen Sie zu Anwendungsgruppen.
  2. Klicken Sie auf Anwendungsgruppe hinzufügen.
  3. 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.

  4. 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/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 die Kennung der vertrauenden Seite einen Anbieter von Workload Identity-Pool eindeutig identifiziert.

    Sie benötigen die Kennung der vertrauenden Seite später, wenn Sie den Anbieter des Identitätspools für Arbeitslasten konfigurieren.

  5. Klicken Sie auf Next (Weiter).

  6. Wählen Sie auf der Seite Zugriffssteuerungsrichtlinie anwenden eine entsprechende Zugriffsrichtlinie aus und klicken Sie dann auf Weiter.

  7. Fügen Sie auf der Seite Anwendungsberechtigungen konfigurieren die zuvor erstellte Clientanwendung hinzu. Klicken Sie anschließend auf Weiter.

  8. Prüfen Sie auf der Seite Zusammenfassung die Einstellungen und klicken Sie auf Weiter.

  9. Klicken Sie auf Schließen, um das Dialogfeld zu schließen.

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.

SAML (AD FS)

Sie können Anwendungen erlauben, die Identität eines Dienstkontos in Google Cloud zu übernehmen. Dazu verwenden Sie eine SAML 2.0-Assertion aus Active Directory Federation Services (AD FS).

Damit Anwendungen eine SAML-Assertion von AD FS anfordern können, die für die Workload Identity-Föderation verwendet werden kann, müssen Sie eine Vertrauensstellung der vertrauenden Seite erstellen. So erstellen Sie eine Vertrauensstellung der vertrauenden Seite in AD FS für Windows Server 2019:

  1. Öffnen Sie das AD FS MMC-Snap-in und gehen Sie zu Vertrauensstellungen der vertrauenden Seite.
  2. Klicken Sie auf Vertrauensstellung der vertrauenden Seite hinzufügen.
  3. Wählen Sie auf der Seite Willkommen des Assistenten Vertrauensstellung der vertrauenden Seite hinzufügen die Option Ansprüche berücksichtigen aus und klicken Sie auf Starten.
  4. Wählen Sie auf der Seite Datenquelle auswählen die Option Daten über die vertrauende Seite manuell eingeben aus. Klicken Sie anschließend auf Weiter.
  5. Geben Sie auf der Seite Anzeigename angeben einen Namen für die Vertrauensstellung ein. Klicken Sie anschließend auf Weiter.
  6. Klicken Sie auf der Seite Zertifikat konfigurieren auf Weiter. Ein Verschlüsselungszertifikat ist nicht erforderlich, da die Workload Identity-Föderation keine verschlüsselten SAML-Assertions unterstützt.
  7. Behalten Sie auf der Seite URL konfigurieren die Standardeinstellungen bei und klicken Sie auf Weiter.

  8. 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/POOL_ID/providers/PROVIDER_ID

    Dabei gilt:

    • 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 die Kennung der vertrauenden Seite einen Anbieter von Workload Identity-Pool eindeutig identifiziert.

    Sie benötigen die Kennung der vertrauenden Seite später, wenn Sie den Anbieter des Identitätspools für Arbeitslasten konfigurieren.

  9. Klicken Sie auf Next (Weiter).

  10. Wählen Sie auf der Seite Zugriffssteuerungsrichtlinie auswählen die entsprechende Zugriffssteuerungsrichtlinie aus und klicken Sie auf Weiter.

  11. Prüfen Sie auf der Seite Bereit zum Hinzufügen der Vertrauensstellung die Einstellungen und klicken Sie auf Weiter.

  12. 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 Anspruchsausstellungsrichtlinie:

  1. 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.
  2. Klicken Sie auf Regel hinzufügen.
  3. Wählen Sie auf der Seite Regeltyp auswählen des Assistenten Regel für den Anspruch hinzufügen die Option Eingehenden Anspruch transformieren aus. Klicken Sie anschließend auf Weiter.

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

  5. Wählen Sie Alle Anspruchswerte übergeben aus und klicken Sie auf Fertigstellen.

  6. Konfigurieren Sie optional zusätzliche Regeln, um weitere Attribute in die SAML-Assertions aufzunehmen.

  7. Klicken Sie auf OK, um das Dialogfeld für die Anspruchsausstellungsrichtlinie zu schließen.

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 mithilfe der folgenden Kennzeichnungen die Fähigkeit, die Identität eines Dienstkontos zu übernehmen, bestimmten EC2-Instanzen oder Rollen zuweisen:

Gewähren Sie Zugriff auf eine bestimmte EC2-Instanz: 

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/arn:aws:sts::ACCOUNT_ID:assumed-role/AWS_ROLE/AWS_ROLE_SESSION_NAME

Gewähren Sie Zugriff über Rollen: 

principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.aws_role/arn:aws:sts::ACCOUNT_ID:assumed-role/AWS_ROLE

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

OIDC (AD FS)

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.

Optional können Sie eine Attributbedingung verwenden, um zusätzliche Anforderungen zu definieren, die AD FS-Zugriffstokens erfüllen müssen. Die folgende Bedingung definiert beispielsweise, 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

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'

SAML (AD FS)

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. Beispiel:

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]

Optional können Sie eine Attributbedingung verwenden, die alle SAML-Assertions erfüllen müssen. 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

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 -pool 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 eine Föderation mit Azure, GitHub Actions oder einem anderen OIDC-kompatiblen Anbieter durchführen.
    • Sie können die Workload Identity-Föderation über einen SAML 2.0-Identitätsanbieter nicht mit der Cloud Console konfigurieren. Sie müssen die gcloud CLI 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.
    • Zulässige Zielgruppen: Anwendungs-ID-URI, den Sie bei der Registrierung der Anwendung in Azure AD verwendet haben.

    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.
    • Zulässige Zielgruppen: Erwartete Zielgruppe von ID-Tokens.

    OIDC (AD FS)

    • 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://ADFS_DOMAIN/adfs, wobei ADFS_DOMAIN der Name der öffentlichen Domain des AD FS-Servers oder der Farm ist.

  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:

    OIDC (AD FS) 

    gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://ADFS_DOMAIN/adfs" \
    --allowed-audiences="RELYING_PARTY_ID" \
    --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"

    SAML (AD FS) 

    curl -O https://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"

    Dabei gilt:

    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"

Nächste Schritte