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:
- Rufen Sie Anmeldedaten vom vertrauenswürdigen Identitätsanbieter ab.
- Tauschen Sie die Anmeldedaten gegen ein Token des Security Token Service aus.
- 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.
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:
Erstellen Sie eine Azure AD-Anwendung und ein Diensthauptkonto.
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:
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.
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:
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.
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:
- Ihre Anwendung verwendet eine HTTP-Bibliothek, die IWA unterstützt.
- 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.
- Sie haben IWA für den User-Agent aktiviert, den Ihre Anwendung in HTTP-Anfragen verwendet.
Clientanwendung registrieren
So registrieren Sie eine Anwendung in AD FS für Windows Server 2019:
- Öffnen Sie das AD FS MMC-Snap-in und gehen Sie zu Anwendungsgruppen.
- Klicken Sie auf Anwendungsgruppe hinzufügen.
- Geben Sie auf Begrüßungsseite einen Namen für den Client ein und wählen Sie Serveranwendung aus. Klicken Sie anschließend auf Weiter.
- 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 wiehttp://localhost/
verwenden. Klicken Sie anschließend auf Weiter. - 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.
- 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-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:
- Ö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/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.
Klicken Sie auf Next (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
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:
- Öffnen Sie das AD FS MMC-Snap-in und gehen Sie zu Vertrauensstellungen der vertrauenden Seite.
- Klicken Sie auf Vertrauensstellung der vertrauenden Seite hinzufügen.
- 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.
- 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.
- Geben Sie auf der Seite Anzeigename angeben einen Namen für die Vertrauensstellung ein. Klicken Sie anschließend auf Weiter.
- 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.
- Behalten Sie auf der Seite URL konfigurieren die Standardeinstellungen bei und 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/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.
Klicken Sie auf Next (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 Anspruchsausstellungsrichtlinie:
- 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.
- 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.
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.
- Name der Anspruchsregel:
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.
Föderation konfigurieren
So stellen Sie eine Verbindung mit Ihrem externen Identitätsanbieter her:
- Bereiten Sie ein Google Cloud-Projekt vor, das den Workload Identity-Pool und -Anbieter enthält.
- Definieren Sie eine Attributzuordnung und eine optionale Attributbedingung, mit denen die Anmeldedaten des Identitätsanbieters externen Identitäten zugeordnet werden.
- 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:
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.Aktualisieren Sie die Organisationsrichtlinie für Ihre Organisation, um die Föderation zuzulassen.
IAM, Resource Manager, Service Account Credentials, and Security Token Service (STS) APIs aktivieren.
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 namensattribute.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 aufprod
odertest
festzulegen:attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"
Diese Zuordnung verwendet die Funktion
extract
, um ein benutzerdefiniertes Attributaws_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:
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.Rufen Sie in einem Webbrowser
https://jwt.ms/
auf und fügen Sie das Zugriffstoken in das Textfeld ein.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 dieNameID
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
Rufen Sie in der Cloud Console die Seite Neuer Arbeitslastanbieter und -pool auf.
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.
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.
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
, wobeiTENANT_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
, wobeiADFS_DOMAIN
der Name der öffentlichen Domain des AD FS-Servers oder der Farm ist.
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 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.
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:
PROVIDER_ID
: eindeutige ID für den Anbieter.POOL_ID
: ID des Pools.AWS_ACCOUNT_ID
: 12-stellige Nummer, die Ihr AWS-Konto identifiziert.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben.CONDITIONS
: Zuvor identifizierte Attributbedingung. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
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:
PROVIDER_ID
: eindeutige ID für den Anbieter.POOL_ID
: ID des Pools.TENANT_ID
: Mandanten-ID (GUID) Ihres Azure AD-Mandanten.APPLICATION_ID_URI
: Anwendungs-ID-URI, den Sie bei der Registrierung der Anwendung in Azure AD verwendet haben.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben.CONDITIONS
: Zuvor identifizierte Attributbedingung. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
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:
PROVIDER_ID
: eindeutige ID für den Anbieter.POOL_ID
: ID des Pools.OWNER
: Name des Nutzers oder der Organisation, der das Repository gehört.REPOSITORY
: Name des Repositorys.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben.CONDITIONS
: Zuvor identifizierte Attributbedingung. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
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:
PROVIDER_ID
: eindeutige ID für den Anbieter.POOL_ID
: ID des Pools.ISSUER
: Aussteller-URI, wie in OIDC-Metadaten definiert.AUDIENCE
: erwartete Zielgruppe von ID-Tokens. Für viele Anbieter entspricht die Zielgruppe der Client-ID.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben.CONDITIONS
: Zuvor identifizierte Attributbedingung. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
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:
POOL_ID
: ID des Pools.ADFS_DOMAIN
: Öffentlicher Domainname des AD FS-Servers oder der Farm.RELYING_PARTY_ID
: ID der vertrauenden Seite der Web API-Anwendung für den Workload Identity-Föderationspool 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.
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:
POOL_ID
: ID des Pools.IDP_METADATA_PATH
: lokaler Dateipfad zum Abrufen des IdP-Metadaten-Dokuments des SAML-Identitätsanbieters.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben.CONDITIONS
: Zuvor identifizierte Attributbedingung. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
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:
DOMAIN
: Domainname Ihres AD FS-Servers oder Ihrer Serverfarm.POOL_ID
: ID des Pools.MAPPINGS
: durch Kommas getrennte Liste von Attributzuordnungen, die Sie zuvor identifiziert haben.CONDITIONS
: Zuvor identifizierte Attributbedingung. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
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
- Kurzlebige Anmeldedaten mithilfe der Identity-Föderation abrufen
- Weitere Informationen zur Workload Identity-Föderation
- Workload Identity-Pools und -Anbieter verwalten