Mitarbeiteridentitätsföderation

Mit der Workforce Identity-Föderation können Nutzer in Ihrem externen Identitätsanbieter (Identity Provider, IdP) die Einmalanmeldung (Single Sign-On, SSO) verwenden, um auf Google Cloud -Ressourcen zuzugreifen.

Was ist Mitarbeiteridentitätsföderation?

Mit der Mitarbeiteridentitätsföderation können Sie Ihren externen Identitätsanbieter (IdP) verwenden, um Ihre Mitarbeiter zu authentifizieren – Nutzer und Gruppen von Nutzern wie Mitarbeiter, Partner und Auftragnehmer. Ihre Nutzer können dann über Ihren IdP per Einmalanmeldung (SSO) auf Google Cloud zugreifen. Mit IAM-Richtlinien (Identity and Access Management) können Sie Ihren Mitarbeitern den Zugriff auf Google Cloud Dienste autorisieren Google Cloud .

Föderation und Synchronisierung

Bei der Workforce Identity-Föderation werden Identitäten von Ihrem IdP eingebunden. Daher werden keine Nutzerkonten in Google Cloudgespeichert. Daher ist die Mitarbeiteridentitätsföderation synchronisationslos. Sie müssen also keine Tools verwenden, um Nutzeridentitäten von Ihrem IdP mit von Google verwalteten Identitäten zu synchronisieren, für die Google-Konten erforderlich sind. Wenn Sie beispielsweise die Mitarbeiteridentitätsföderation verwenden, müssen Sie nicht Google Cloud Directory Sync (GCDS) von Cloud Identity verwenden.

Mitarbeiteridentitätsföderation im Vergleich zur Identitätsföderation von Arbeitslasten

Die Workforce Identity-Föderation föderiert Nutzeridentitäten, während die Workload Identity-Föderation Arbeitslastidentitäten föderiert.

Weitere Informationen finden Sie unter Workload Identity-Föderation.

Attributbasierter Zugriff

Die Mitarbeiteridentitätsföderation erweitert die Identitätsfunktionen von Google Cloud, um den attributbasierten Zugriff zu unterstützen. Bei einigen IdPs werden Attribute auch als Ansprüche oder Assertions bezeichnet.

Nach der Nutzerauthentifizierung werden die vom IdP empfangenen Attribute verwendet, um den Umfang des Zugriffs auf die Google Cloud -Ressourcen zu bestimmen.

Unterstützte Protokolle

Sie können die Mitarbeiteridentitätsföderation mit jedem IdP verwenden, der OpenID Connect (OIDC) oder SAML 2.0 unterstützt, z. B. Microsoft Entra ID, Active Directory Federation Services (AD FS), Okta und andere.

Wichtige Konzepte

In diesem Abschnitt werden die wichtigsten Konzepte der Mitarbeiteridentitätsföderation beschrieben.

Identitätspools von Mitarbeitern

Mit Workforce Identity-Pools können Sie Gruppen von Workforce-Identitäten und deren Zugriff auf Google Cloud Ressourcen verwalten.

Mit Pools haben Sie folgende Möglichkeiten:

  • Nutzeridentitäten gruppieren, zum Beispiel: employees oder partners
  • IAM-Zugriff auf einen gesamten Pool oder einen Teil davon gewähren.
  • Identitäten von einem oder mehreren IdPs verbinden.
  • Richtlinien für eine Gruppe von Nutzern festlegen, die ähnliche Zugriffsberechtigungen benötigen.
  • IdP-spezifische Konfigurationsinformationen angeben, einschließlich Attributzuordnung und Attributbedingungen.
  • Google Cloud CLI und den API-Zugriff für Identitäten von Drittanbietern aktivieren.
  • Logzugriff von Nutzern in einem Pool auf Cloud-Audit-Logs zusammen mit der Pool-ID.

Sie können mehrere Pools erstellen. Ein Beispiel für einen solchen Ansatz finden Sie unter Beispiel: Mehrere Mitarbeiteridentitätspools.

Pools werden auf Google Cloud -Organisationsebene konfiguriert. Das hat folgende Auswirkungen:

  • Wenn Sie zum ersten Mal die Mitarbeiteridentitätsföderation für Ihre Organisation einrichten, geben Sie einen eindeutigen Namen für den Pool an. Der Name muss für alle Pools in der Organisation eindeutig sein und sollte die darin enthaltenen Identitäten klar beschreiben.
  • Wenn Sie die entsprechenden IAM-Berechtigungen zum Aufrufen des Pools haben, kann er in allen Projekten und Ordnern innerhalb der Organisation anhand seines Namens referenziert werden.

Anbieter von Pools für Workforce Identity

Ein Anbieter von Pools für Workforce Identity ist eine Entität, die eine Beziehung zwischen Ihrer Google Cloud -Organisation und Ihrem IdP beschreibt.

Die Mitarbeiteridentitätsföderation entspricht der Spezifikation des OAuth 2.0-Tokenaustauschs (RFC 8693). Sie stellen Anmeldedaten von Ihrem externen Identitätsanbieter dem Security Token Service bereit. Die Identität in den Anmeldedaten wird von ihm geprüft und im Austausch wird ein kurzlebiges Google Cloud Zugriffstoken zurückgegeben.

OIDC-Vorgangstypen

Für OIDC-Anbieter unterstützt die Mitarbeiteridentitätsföderation sowohl den Autorisierungscodefluss als auch den impliziten Ablauf. Der Autorisierungscode-Ablauf wird als der sicherste betrachtet, da Tokens nach der Authentifizierung der Nutzer vom IdP in einer separaten, sicheren Backend-Transaktion direkt vom IdP zu Google Cloudzurückgegeben werden. Daher können Codeablauf-Transaktionen Tokens jeder Größe abrufen, sodass Sie mehr Anforderungen für die Attributzuordnung und Attributbedingung verwenden können. Im impliziten Ablauf wird das ID-Token dagegen vom IdP an den Browser zurückgegeben. Tokens unterliegen den jeweiligen URL-Größenbeschränkungen von Browsern.

Google Cloud Console für die Mitarbeiteridentitätsföderation

Nutzer in einem Mitarbeiteridentitätspool können auf die Google Cloud Console für die Mitarbeiteridentitätsföderation zugreifen, die auch als Console (föderiert) bezeichnet wird. In der Console erhalten diese Nutzer über die Benutzeroberfläche Zugriff aufGoogle Cloud Produkte, die die Mitarbeiteridentitätsföderation unterstützen.

SCIM-Unterstützung

Wenn Ihr IdP System for Cross-domain Identity Management (SCIM) unterstützt, können Sie ihn so konfigurieren, dass Gruppen in Google Cloudbereitgestellt und verwaltet werden.

SCIM-Mandanten für die Mitarbeiteridentitätsföderation unterstützen die Freigabe in Gemini Enterprise. Nachdem Sie SCIM-Mandanten in Ihrer IdP-Anwendung und in der Workforce Identity-Föderation konfiguriert haben, können Gemini Enterprise-Nutzer NotebookLM-Notebooks für eine Gruppe freigeben, indem sie den Namen der Gruppe anstelle der Objekt-ID (UUID) verwenden. Weitere Informationen zum Freigeben von Notebooks für Gruppen finden Sie unter Notebooks für Gruppen freigeben.

Wenn Sie die SCIM-Unterstützung für die Mitarbeiteridentitätsföderation verwenden, gelten die folgenden Überlegungen:

  • Sie müssen einen Workforce Identity-Pool und einen Anbieter einrichten, bevor Sie einen SCIM-Mandanten konfigurieren.
  • Jeder Mitarbeiteridentitätspool unterstützt nur einen SCIM-Mandanten. Wenn Sie einen neuen SCIM-Mandanten im selben Workforce Identity-Pool konfigurieren möchten, müssen Sie zuerst den vorhandenen Mandanten löschen. Wenn Sie einen SCIM-Mandanten löschen, haben Sie zwei Möglichkeiten:
    • Vorläufiges Löschen (Standard): Wenn Sie einen SCIM-Mandanten löschen, beginnt ein Zeitraum von 30 Tagen für das vorläufige Löschen. Während dieser Zeit ist der Mandant ausgeblendet und kann nicht verwendet werden. Außerdem können Sie keinen neuen SCIM-Mandanten im selben Mitarbeiteridentitäts-Pool erstellen.
    • Endgültiges Löschen:Wenn Sie einen SCIM-Mandanten dauerhaft und sofort löschen möchten, verwenden Sie das Flag --hard-delete mit dem Befehl „delete“. Diese Aktion ist irreversibel. Sie können jedoch sofort nach Abschluss des Löschvorgangs einen neuen SCIM-Mandanten im selben Mitarbeiteridentitätspool erstellen.
    Alternativ können Sie einen neuen Mitarbeiteridentitätspool und einen neuen SCIM-Mandanten erstellen oder einen Mitarbeiteridentitätspool verwenden, der noch nicht mit einem SCIM-Mandanten konfiguriert wurde.
  • Wenn Sie SCIM verwenden, ordnen Sie Attribute sowohl im Mitarbeiteridentitäts-Poolanbieter als auch im SCIM-Mandanten zu. Das Attribut „google.subject“ muss eindeutig auf dieselben Identitäten verweisen. Sie geben `google.subject` im Mitarbeiteridentitätspoolanbieter mit dem Flag --attribute-mapping und im SCIM-Mandanten mit dem Flag --claim-mapping an. Nicht eindeutige Identitätswerte, die auf diese Weise zugeordnet werden, können dazu führen, dass unterschiedliche Identitäten in Ihrem IdP in Google Cloudals dieselbe Identität behandelt werden. Daher kann der Zugriff, der einer Nutzer- oder Gruppenidentität gewährt wird, auch auf andere Identitäten angewendet werden. Wenn Sie den Zugriff für eine Identität widerrufen, wird er möglicherweise nicht für alle Identitäten widerrufen. Einige Identitäten behalten dann den Zugriff.
  • Wenn Sie SCIM zum Zuordnen von Gruppen verwenden möchten, legen Sie `--scim-usage=enabled-for-groups` fest. Wenn Sie Gruppen mit SCIM zuordnen, wird jede Gruppenzuordnung, die im Workforce Identity-Poolanbieter definiert ist, ignoriert. Bei SCIM-verwalteten Gruppen ist das zugeordnete Attribut `google.group` und nicht `google.groups`. `google.groups` bezieht sich nur auf Gruppen mit Tokenzuordnung.
  • Bei Verwendung von SCIM können tokenbasierte Attribute, die mit `--attribute-mapping` zugeordnet sind, weiterhin für die Authentifizierung und in Hauptkonto-IDs verwendet werden.
  • Bei der Microsoft Entra ID-Konfiguration dürfen Sie beim Erstellen des Workforce Identity-Pool-Anbieters keine --extended-attributes-Flags verwenden.

Attribute

Ihr IdP stellt Attribute bereit, die von einigen IdPs als Anforderungen bezeichnet werden. Attribute enthalten Informationen über Ihre Nutzer. Sie können diese Attribute in Attributzuordnungen und Attributbedingungen verwenden.

Attributzuordnungen

Sie können diese Attribute zur Verwendung durch Google Cloud mit der Common Expression Language (CEL) zuordnen.

In diesem Abschnitt werden die erforderlichen und optionalen Attribute beschrieben, dieGoogle Cloud bereitstellt.

Sie können auch benutzerdefinierte Attribute bei Ihrem IdP definieren, die dann von bestimmten Google Cloud -Produkten verwendet werden können. Beispiel: IAM-Zulassungsrichtlinien.

Die maximale Größe für Attributzuordnungen beträgt 16 KB. Wenn die Größe der Attributzuordnungen das Limit von 16 KB überschreitet, schlägt der Anmeldeversuch fehl.

Die Attribute sind:

  • google.subject (erforderlich): eine eindeutige Kennung für den Nutzer, der sich authentifiziert. Es ist oft die Subjekt-Assertion des JWT, da Cloud-Audit-Logs den Inhalt dieses Feldes als Hauptkonto erfassen. In diesem Feld können Sie IAM für Autorisierungsentscheidungen konfigurieren. Wir empfehlen, keinen änderbaren Wert zu verwenden, da der Nutzer den Zugriff verliert, wenn Sie den Wert im Nutzerverzeichnis des IdP ändern.

    Die maximale Länge beträgt 127 Bytes.

  • google.groups (optional): die Sammlung von Gruppen, in denen der sich authentifizierende Nutzer Mitglied ist. Sie können mithilfe einer Teilmenge der CEL einen logischen Ausdruck konfigurieren, der ein Array von Strings erzeugt. Sie können dieses Feld auch verwenden, um IAM für Autorisierungsentscheidungen zu konfigurieren. Für google.groups gelten die folgenden Einschränkungen:

    • Wir empfehlen, den Gruppennamen auf 40 Zeichen zu beschränken.

    • Wenn ein einzelner Nutzer mehr als 400 Gruppen angehört, schlägt der Anmeldeversuch dieses Nutzers fehl. Um dieses Problem zu beheben, müssen Sie in der Assertion einen kleineren Satz von Gruppen definieren und nur die Gruppen zuordnen, die zum Verknüpfen des Nutzers mit Google Cloudverwendet werden.

    • Wenn Sie dieses Attribut verwenden, um Zugriff in IAM zu gewähren, wird jedem Mitglied in den zugeordneten Gruppen Zugriff gewährt. Daher sollten Sie sicherstellen, dass nur autorisierte Nutzer in Ihrer Organisation die Mitgliedschaft der zugeordneten Gruppen ändern können.

  • google.display_name (optional): Attribut, mit dem der Name des angemeldeten Nutzers in der Google Cloud Console festgelegt wird. Dieses Attribut kann weder in IAM-Zulassungsrichtlinien noch in der Attributbedingung verwendet werden.

    Die maximale Länge beträgt 100 Bytes.

  • google.profile_photo (optional): eine URL zum Miniaturansichtsbild des Nutzers. Wir empfehlen ein Foto mit 400 x 400 Pixeln. Wenn dieses Attribut festgelegt ist, wird das Bild in der Google Cloud -Konsole als Profilbild des Nutzers angezeigt. Wenn dieser Wert nicht festgelegt ist oder nicht abgerufen werden kann, wird stattdessen ein generisches Nutzersymbol angezeigt. Dieses Attribut kann weder in IAM-Zulassungsrichtlinien noch in der Attributbedingung verwendet werden.

  • google.posix_username (optional): ein eindeutiger POSIX-konformer Nutzernamensstring, der für Folgendes verwendet wird:

    Dieses Attribut kann weder in IAM-Zulassungsrichtlinien noch in der Attributbedingung verwendet werden. Die maximale Länge beträgt 32 Zeichen.

  • google.email (Optional): Ein Attribut, das verwendet wird, um E-Mail-Adressen von angemeldeten, verbundenen Nutzern vom IdP zu Produkten zuzuordnen, die Sie mit der OAuth-Client-Integration für Workforce Identity Federation integrieren. Dieses Attribut kann weder in IAM-Zulassungsrichtlinien noch in der Attributbedingung verwendet werden.

    Wenn Sie beispielsweise E-Mail-Adressen aus Okta mit dem OIDC-Protokoll zuordnen möchten, fügen Sie google.email=assertion.email in Ihre Attributzuordnung ein.

    Beispiele für Google Cloud Produkte, die die Integration von OAuth-Clients unterstützen:

  • attribute.KEY (optional): ein externes IdP-definiertes Attribut, das im IdP-Token eines Nutzers vorhanden ist. Mit dem benutzerdefinierten Attribut können Sie Ihre Autorisierungsstrategie in einer IAM-Zulassungsrichtlinie definieren.

    In Ihrem IdP können Sie beispielsweise ein Attribut wie die Kostenstelle des Nutzers als costcenter = "1234" definieren und dann so auf den Prinzipal verweisen:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234

    Nachdem Sie diesem Prinzipalzugriff auf Google Cloud Ressourcen gewährt haben, haben alle Identitäten, die im IdP so konfiguriert sind, dass das Attribut costcenter auf 1234 gesetzt ist, Zugriff auf die Ressourcen.

    Sie können maximal 50 benutzerdefinierte Attributzuordnungsregeln konfigurieren. Die maximale Größe einer solchen Regel beträgt 2.048 Zeichen.

    Auch wenn es keine Einschränkungen für die Attribute gibt, die Sie hier zuordnen können, empfehlen wir dringend, Attribute auszuwählen, deren Werte stabil sind. Beispielsweise kann sich ein Attribut wie attribute.job_description aus verschiedenen Gründen ändern (z. B. zur Verbesserung der Lesbarkeit). Alternativ können Sie attribute.role verwenden. Änderungen daran weisen auf eine Änderung der zugewiesenen Verantwortlichkeit hin und richten sich nach den Änderungen des Zugriffs, der dem Nutzer gewährt wird.

Sie können Attributwerte mit den Standard-CEL-Funktionen transformieren. Sie können auch die folgenden benutzerdefinierten Funktionen verwenden:

  • Die split-Funktion teilt einen String mit dem angegebenen Trennzeichenwert auf. Wenn Sie beispielsweise das Attribut username aus einem E-Mail-Adressattribut extrahieren möchten, indem Sie seinen Wert bei @ aufteilen und den ersten String verwenden, verwenden Sie die folgende Attributzuordnung: 

    attribute.username=assertion.email.split("@")[0]

  • Die join-Funktion verbindet eine Liste von Strings im angegebenen Trennzeichenwert. Wenn Sie beispielsweise das benutzerdefinierte Attribut department durch Verketten einer Liste von Strings mit . als Trennzeichen ausfüllen möchten, verwenden Sie die folgende Attributzuordnung: 

    attribute.department=assertion.department.join(".")

Attributbedingungen

Attributbedingungen sind optionale CEL-Ausdrücke, mit denen Sie Einschränkungen für die von Google Cloud akzeptierten Identitätsattribute festlegen können.

Die Verwendung von Attributbedingungen bietet unter anderem folgende Vorteile:

  • Mit Attributbedingungen können Sie nur einen Teil der externen Identitäten zur Authentifizierung bei Ihrem Google Cloud -Projekt zulassen. Beispielsweise möchten Sie möglicherweise, dass nur Identitäten in einem bestimmten Team sich anmelden können, insbesondere wenn Sie einen öffentlichen IdP verwenden. Ein weiteres Beispiel: Sie können Ihrem Buchhaltungsteam die Anmeldung erlauben, aber nicht Ihrem Entwicklerteam.
  • Mit Attributbedingungen können Sie verhindern, dass Anmeldedaten, die für eine andere Plattform vorgesehen sind, für Google Cloudverwendet werden und umgekehrt. Dies trägt dazu bei, das Problem der Confused Deputy Attack zu vermeiden. #### Attributbedingungen für mandantenfähige IdPs

Die Mitarbeiteridentitätsföderation verwaltet kein Verzeichnis mit Nutzerkonten, sondern implementiert anmeldedatenbasierte Identitäten. Wenn also zwei Tokens vom selben Identitätsanbieter (IdP) ausgestellt werden und ihre Anforderungen demselben google.subject-Wert zugeordnet sind, wird davon ausgegangen, dass die beiden Tokens denselben Nutzer identifizieren. Die Mitarbeiteridentitätsföderation prüft und verifiziert die Aussteller-URL des Tokens, um herauszufinden, welcher IdP ein Token ausgestellt hat.

Mandantenfähige IdPs wie GitHub und Terraform Cloud verwenden für alle ihre Kunden eine einzige Aussteller-URL. Für diese Anbieter identifiziert die Aussteller-URL GitHub oder Terraform Cloud insgesamt und nicht eine bestimmte GitHub- oder Terraform Cloud-Organisation.

Wenn Sie diese Identitätsanbieter verwenden, reicht es nicht aus, dass die Mitarbeiteridentitätsföderation die Aussteller-URL eines Tokens prüfen kann, um sicherzugehen, dass sie von einer vertrauenswürdigen Quelle stammt und seine Anforderungen vertrauenswürdig sind. Wenn Ihr mandantenfähiger IdP eine einzelne Aussteller-URL hat, müssen Sie Attributbedingungen verwenden, um den Zugriff auf den richtigen Mandanten zu beschränken.

Detailliertes Audit-Logging

Detaillierte Audit-Logs sind eine Funktion der Mitarbeiteridentitätsföderation, mit der Attribute, die von Ihrem IdP empfangen wurden, in Cloud-Audit-Logs protokolliert werden.

Sie können das detaillierte Audit-Logging aktivieren, wenn Sie Ihren Workforce Identity-Pool-Anbieter erstellen.

Informationen zur Fehlerbehebung bei Attributzuordnungsfehlern mit detaillierter Audit-Protokollierung finden Sie unter Allgemeine Attributzuordnungsfehler.

JSON-Webschlüssel

Der Personalpoolanbieter kann auf JSON-Webschlüssel (JWKs) zugreifen, die von Ihrem Identitätsanbieter im Feld jwks_uri des Dokuments /.well-known/openid-configuration bereitgestellt werden. Wenn Ihr OIDC-Anbieter diese Informationen nicht bereitstellt oder der Aussteller nicht öffentlich zugänglich ist, können Sie die JWKs beim Erstellen oder Aktualisieren des OIDC-Anbieters manuell hochladen.

Mitarbeiter-Hauptkonto-IDs für IAM-Richtlinien

In der folgenden Tabelle sind die Hauptkonto-Kennungen aufgeführt, mit denen Sie einzelnen Nutzern und Nutzergruppen Rollen zuweisen können.

Identitäten ID-Format
Einzelne Identität im Workforce Identity-Pool principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Alle Mitarbeiteridentitäten in einer Gruppe principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Alle Mitarbeiteridentitäten mit einem bestimmten Attributwert principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Alle Identitäten in einem Mitarbeiteridentitätspool principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Eine vollständige Liste der Hauptkonto-IDs finden Sie unter Hauptkonto-IDs.

Weitere Hinweise

In diesem Abschnitt werden weitere Aspekte bei der Verwendung der Mitarbeiteridentitätsföderation beschrieben.

Organisationsübergreifenden Zugriff einschränken

Hauptkonten des Mitarbeiteridentitätspools können nicht direkt auf Ressourcen außerhalb der Organisation zugreifen, zu der sie gehören. Wenn ein Hauptkonto jedoch die Berechtigung erhält, die Identität eines Dienstkontos innerhalb der Organisation zu übernehmen, kann diese Einschränkung umgangen werden, da Dienstkonten nicht gleichermaßen eingeschränkt sind.

Workforce-Pool-Nutzerprojekt

Die meisten Google Cloud APIs wenden die Abrechnung und die Kontingentnutzung für das Projekt an, das die Ressource enthält, auf die Ihre API-Anfrage zugreift. Diese APIs werden als ressourcenbasierte APIs bezeichnet. Für einige Google Cloud APIs wird auf das mit dem Client verknüpfte Projekt angewendet. Diese werden als clientbasierte APIs bezeichnet. Das Projekt, das für Abrechnungs- und Kontingentzwecke verwendet wird, wird als Kontingentprojekt bezeichnet.

Wenn Sie eine Konfigurationsdatei für die Mitarbeiteridentitätsföderation erstellen, geben Sie ein Nutzerprojekt für Personalpools an. Mit diesem Projekt wird Ihre Anwendung für die Google APIs identifiziert, die sie aufruft. Das Nutzerprojekt für Personalpools wird auch als Standardkontingentprojekt für clientbasierte APIs verwendet, es sei denn, Sie verwenden die gcloud CLI, um die API-Anfrage zu starten. Sie benötigen die Berechtigung serviceusage.services.use, die in der Rolle "Service Usage-Nutzer" (roles/serviceusage.serviceUsageConsumer) enthalten, für das von Ihnen angegebene Projekt.

Weitere Informationen zum Kontingentprojekt, zu ressourcenbasierten APIs und zu clientbasierten APIs finden Sie unter Kontingentprojekte – Übersicht.

Beispiel: Mehrere Mitarbeiteridentitätspools

Dieser Abschnitt enthält ein Beispiel für die typische Verwendung mehrerer Pools.

Sie können einen Pool für Mitarbeiter und einen anderen für Partner erstellen. Multinationale Organisationen können separate Pools für verschiedene Abteilungen in ihrer Organisation erstellen. Pools ermöglichen eine verteilte Verwaltung, bei der verschiedene Gruppen ihren spezifischen Pool unabhängig verwalten können, wobei Rollen nur den Identitäten im Pool gewährt werden.

Nehmen wir beispielsweise an, dass ein Unternehmen namens „Enterprise Example Organization“ ein anderes Unternehmen mit dem Namen „Partner Example Organization Inc.“ beauftragt, DevOps-Dienste von Google Kubernetes Engine (GKE) bereitzustellen. Damit die Mitarbeiter der Partner-Beispielorganisation die Dienste bereitstellen können, müssen sie auf die Google Kubernetes Engine (GKE) und andere Google Cloud Ressourcen in der Organisation der Enterprise-Beispielorganisation zugreifen dürfen. Die Enterprise Example Organization hat bereits einen Workforce Identity-Pool namens enterprise-example-organization-employees.

Damit die Partner-Beispielorganisation den Zugriff auf die Ressourcen der Enterprise-Beispielorganisation verwalten kann, erstellt die Enterprise-Beispielorganisation einen separaten Workforce-Pool für Workforce-Nutzer der Partner-Beispielorganisation, sodass die Partner-Beispielorganisation ihn verwalten kann. Die Enterprise Example Organization stellt den Workforce-Pool einem Administrator der Partner Example Organization zur Verfügung. Der Administrator der Partner-Beispielorganisation verwendet ihren eigenen IdP, um Zugriff für ihre Mitarbeiter zu gewähren.

Der Administrator der Partner-Beispielorganisation führt dazu die folgenden Aufgaben aus:

  1. Eine Identität wie partner-organization-admin@example.com für den Administrator der Partner Example Organization im IdP der Enterprise Example Organization erstellen, die bereits im Pool namens enterprise-example-organization-employees konfiguriert ist.

  2. Erstellen Sie einen neuen Workforce-Pool namens example-organization-partner.

  3. Erstellen Sie die folgende Zulassungsrichtlinie für den Pool example-organization-partner:

    {
  "bindings": [
    {
      "role": "roles/iam.workforcePoolEditor",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
      ]
    }
  ]
}

  4. Gewähren Sie Rollen für den example-organization-partner-Pool für die Ressourcen, auf die in der Organisation der Partner-Beispielorganisation Zugriff benötigt wird.

Der Administrator der Partner-Beispielorganisation kann jetzt den Pool example-organization-partner für die Verbindung mit seinem IdP konfigurieren. Anschließend können sich Mitarbeiter der Partner-Beispielorganisation mit den IdP-Anmeldedaten der Partner-Beispielorganisation anmelden. Nach der Anmeldung können Mitarbeiter der Partner-Beispielorganisation auf Google Cloud Ressourcen zugreifen, die durch Richtlinien eingeschränkt sind, die von der Enterprise-Beispielorganisation definiert wurden.

Best Practices für Sicherheitsgruppen

In großen Unternehmen erstellen IT-Administratoren häufig Sicherheitsgruppen als Teil eines Best-Practices-Modells für die Zugriffssteuerung. Sicherheitsgruppen steuern den Zugriff auf interne Ressourcen. Darüber hinaus erstellen Unternehmen häufig zusätzliche Gruppen für Mitarbeiter und andere Gruppen für Partner, um dieses Modell zur Zugriffssteuerung auf Cloud-Ressourcen zu erweitern. Dies kann zu einer Verbreitung von tief verschachtelten Gruppen führen, deren Verwaltung sehr schwierig werden kann.

Ihre Organisation hat möglicherweise auch Richtlinien, die die Anzahl der Gruppen beschränken, die Sie erstellen können, um die Hierarchie des Nutzerverzeichnisses angemessen flach zu halten. Eine bessere Lösung zur Vermeidung von Fehlkonfigurationen von IAM-Richtlinien und zur Begrenzung des Wachstums von Gruppen besteht darin, mehrere Pools zu verwenden, um eine breitere Trennung von Nutzern aus verschiedenen Organisations- und Geschäftseinheiten sowie Partnerorganisationen zu erreichen. Anschließend können Sie auf diese Pools und die in diesen Pools enthaltenen Gruppen verweisen, um IAM-Richtlinien zu definieren (siehe Beispiele im Schritt „IAM konfigurieren“).

Einschränkungen von VPC Service Controls

Administrative Funktionen der Mitarbeiteridentitätsföderation, einschließlich APIs für die Mitarbeiterpoolkonfiguration und Security Token Service APIs, unterstützen VPC Service Controls nicht. Google Cloud -Produkte, die sowohl die Mitarbeiteridentitätsföderation als auch VPC Service Controls unterstützen, funktionieren jedoch wie dokumentiert und unterliegen den Richtlinienprüfungen von VPC Service Controls. Außerdem können Sie Drittanbieteridentitäten wie Nutzer von Personalpools und Arbeitslastidentitäten in den Regeln für ein- und ausgehenden Traffic von VPC Service Controls verwenden.

Mitarbeiteridentitätsföderation und wichtige Kontakte

Wenn Sie wichtige Informationen zu Änderungen an Ihrer Organisation oder IhrenGoogle Cloud -Produkten erhalten möchten, müssen Sie bei Verwendung der Mitarbeiteridentitätsföderation Wichtige Kontakte angeben. Cloud Identity-Nutzer können über ihre Cloud Identity-E-Mail-Adresse kontaktiert werden, Nutzer der Mitarbeiteridentitätsföderation werden jedoch über „Wichtige Kontakte“ kontaktiert.

Wenn Sie die Google Cloud Console zum Erstellen oder Verwalten von Workforce Identity-Pools verwenden, wird ein Banner angezeigt, in dem Sie aufgefordert werden, einen wichtigen Kontakt mit den Kategorien Rechtlich und Sperrung zu konfigurieren. Alternativ können Sie einen Kontakt in der Kategorie Alle definieren, wenn Sie keine separaten Kontakte haben. Wenn Sie die Kontakte angeben, wird das Banner entfernt.

Nächste Schritte