Workforce Identity-Föderation

In diesem Dokument werden die wichtigsten Konzepte der Workforce Identity-Föderation beschrieben.

Was ist Workforce Identity-Föderation?

Mit der Workforce Identity-Föderation können Sie einen externen Identitätsanbieter (IdP) verwenden, um eine Gruppe von Nutzern, z. B. Mitarbeiter, Partner und Auftragnehmer, mithilfe von IAM zu authentifizieren und zu autorisieren, damit die Nutzer auf Google Cloud-Dienste zugreifen können. Mit der Workforce Identity-Föderation müssen Sie keine Nutzeridentitäten Ihres vorhandenen IdP mit Google Cloud-Identitäten synchronisieren, wie es bei Google Cloud Directory Sync (GCDS) von Cloud Identity der Fall ist. Workforce Identity-Föderation erweitert die Identitätsfunktionen von Google Cloud um die synchronisationsfreie, attributbasierte Einmalanmeldung.

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

Sie können die Workforce Identity-Föderation mit jedem IdP verwenden, der OpenID Connect (OIDC) oder SAML 2.0 unterstützt, z. B. Azure Active Directory (Azure AD), Active Directory Federation Services (AD FS), Okta und andere.

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. Aus diesem Grund sind Pools in allen Projekten und Ordnern innerhalb der Organisation verfügbar, solange Sie die entsprechenden IAM-Berechtigungen zum Aufrufen des Pools haben. Wenn Sie zum ersten Mal die Mitarbeiteridentitätsföderation für Ihre Organisation einrichten, geben Sie einen Namen für den Pool an. In IAM-Zulassungsrichtlinien müssen Sie auf den Pool anhand seines Namens verweisen. Aus diesem Grund empfehlen wir, den Pool so zu benennen, dass er die enthaltenen Identitäten eindeutig beschreibt.

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-Ablauftypen

Bei OIDC-Anbietern unterstützt die Mitarbeiteridentitätsföderation sowohl den Autorisierungscode-Ablauf 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 Cloud zurü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. Bei einem impliziten Ablauf wird das ID-Token hingegen 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 auf Google Cloud-Produkte, die die Mitarbeiteridentitätsföderation unterstützen.

Attributzuordnungen

Ihr IdP stellt Attribute bereit, die von einigen IdPs als Anforderungen bezeichnet werden. Attribute enthalten Informationen über Ihre Nutzer. 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, die Google 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 4 KB.

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 100 Zeichen zu beschränken.

    • Wenn ein Nutzer mit mehr als 100 Gruppen verknüpft ist, definieren Sie einen kleineren Satz von Gruppen und fügen Sie nur diese Gruppen in Assertions ein, die zur Föderation des Nutzers mit Google Cloud verwendet 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 Console 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 Nutzername-String, 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.

  • attribute.KEY (optional): ein benutzerdefiniertes Attribut, das im IdP-Token eines Nutzers vorhanden ist. Mit diesen benutzerdefinierten Attributen können Sie Ihre Autorisierungsstrategie in einer IAM-Zulassungsrichtlinie definieren. Sie können beispielsweise ein Attribut wie die Kostenstelle des Nutzers definieren: attribute.costcenter = "1234". Dieses Attribut könnte dann in IAM-Bedingungen verwendet werden, um nur Nutzern in dieser Kostenstelle Zugriff zu gewähren.

    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 Cloud verwendet werden und umgekehrt. Dies trägt dazu bei, das Problem der Confused Deputy Attack zu vermieden.

Workforce-Pool-Nutzer in IAM-Richtlinien darstellen

Die folgende Tabelle zeigt die Hauptkonto-Kennungen, mit denen Sie einem einzelnen Nutzer, einer Gruppe von Nutzern, Nutzern mit einer bestimmten Anforderung oder allen Nutzern aus einem Workforce-Pool Rollen zuweisen.

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 Workforce-Identitäten in einer Gruppe principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Alle Workforce-Identitäten mit einem bestimmten Attributwert principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Alle Identitäten in einem Workforce Identity-Pool principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

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.

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 für die Abrechnung und Kontingentzwecke verwendete Projekt wird als Kontingentprojekt bezeichnet.

Wenn Sie eine Konfigurationsdatei für die Mitarbeiteridentitätsföderation erstellen, geben Sie ein Nutzerprojekt für Workforce-Pools an. Mit diesem Projekt wird Ihre Anwendung für die Google APIs identifiziert, die sie aufruft. Das Nutzerprojekt des Workforce-Pools wird auch als Standardkontingentprojekt für clientbasierte APIs verwendet, sofern Sie nicht die gcloud CLI verwenden, um die API-Anfrage zu initiieren. 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 Kontingentprojekt – Übersicht.

Beispiel: Mehrere Workforce Identity-Pools

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 Enterprise Example Organization die Dienste bereitstellen können, müssen sie auf die Google Kubernetes Engine (GKE) und andere Google Cloud-Ressourcen in der Organisation der Partner-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 Partner-Beispielorganisation definiert wurden.

Einfachere Zugriffsverwaltung

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

Die Mitarbeiteridentitätsföderation, APIs für die Mitarbeiterpoolkonfiguration und Security Token Service APIs unterstützen VPC Service Controls nicht. Google Cloud-Produkte, auf die Nutzer der Mitarbeiterpools zugreifen können, unterstützen VPC Service Controls jedoch. Weitere Informationen finden Sie auf der Seite Unterstützte Produkte und Einschränkungen für VPC Service Controls.

Workforce Identity-Föderation und wichtige Kontakte

Wenn Sie wichtige Informationen zu Änderungen an Ihrer Organisation oder zu Google Cloud-Produkten erhalten möchten, müssen Sie Wichtige Kontakte angeben, wenn Sie die Workforce Identity-Föderation verwenden. 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