Mitarbeiteridentitätsföderation

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

Was ist Mitarbeiteridentitätsföderation?

Mit der Mitarbeiteridentitätsföderation können Sie einen externen Identitätsanbieter (Identity Provider, IdP) verwenden, um eine Gruppe von Nutzern, z. B. Mitarbeiter, Partner und Auftragnehmer, per IAM zu authentifizieren und zu autorisieren, damit die Nutzer auf Google Cloud-Dienste zugreifen können. Mit der Mitarbeiteridentitätsfö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. Mitarbeiteridentitätsfö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 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.

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-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 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. 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 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 ein Nutzer mehr als 100 Gruppen angehört, schlägt die Authentifizierung fehl.

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

  • attribute.KEY (optional): ein vom externen 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.

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

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.costcenter/1234

    Nachdem Sie dieser Identitäts-ID Zugriff auf Google Cloud-Ressourcen gewährt haben, haben alle Identitäten, die im IdP so konfiguriert sind, dass das costcenter-Attribut auf 1234 festgelegt 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 Cloud verwendet werden und umgekehrt. Dies trägt dazu bei, das Problem der Confused Deputy Attack zu vermieden.

Attributbedingungen bei der Föderierung mit GitHub oder anderen Identitätsanbietern mit mehreren Mandanten verwenden

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, empfehlen wir Ihnen, Attributbedingungen zu verwenden, um den Zugriff auf den richtigen Mandanten zu beschränken.

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 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 zu Kontingentprojekten, ressourcenbasierten APIs und clientbasierten APIs finden Sie unter Kontingentprojekte – Ü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 [email protected] 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/[email protected]"
      ]
    }
  ]
}

  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 Konfiguration des Mitarbeiterpools 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.

Mitarbeiteridentitätsföderation und wichtige Kontakte

Wenn Sie wichtige Informationen zu Änderungen an Ihrer Organisation oder Ihren Google Cloud-Produkten erhalten möchten, müssen Sie bei der 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