Wenn Sie ein Produkt anbieten oder einen Dienst betreiben, mit dem Kunden Daten oder Ressourcen analysieren oder verwalten können, möchten Ihre Kunden möglicherweise auf Daten oder andere Ressourcen in ihrer Google Cloud-Umgebung zugreifen. Beispiele für solche Produkte und Dienstleistungen:
- Datenanalyseprodukte: Ihre Kunden möchten diese Produkte möglicherweise zur Analyse ihrer Daten in BigQuery verwenden.
- CI/CD-Produkte und -Dienste: Ihre Kunden können diese Dienste verwenden, um Infrastruktur und Anwendungen in ihren Google Cloud-Projekten bereitzustellen.
- Robotic Process Automation (RPA): Ihre Kunden können RPA für Workflows verwenden, z. B. zum Erstellen von Projekten, zum Verwalten des Zugriffs oder zum Automatisieren von Verwaltungsaufgaben in Google Cloud.
Zur Authentifizierung lokaler oder SaaS-Produkte (Software as a Service) bei Google Cloud benötigen Kunden üblicherweise Dienstkontoschlüssel. Diese Schlüssel können jedoch schwierig zu verwalten und zu speichern sein.
Als Anbieter eines On-Premises- oder SaaS-Produkts können Sie Ihren Kunden helfen, ihre Google Cloud-Ressourcen zu schützen, indem Sie ihnen die Möglichkeit geben, die Identitätsföderation von Arbeitslasten für den Zugriff auf ihre Google Cloud-Ressourcen zu verwenden. Beispiele für Dienste, bei denen Kunden bereits die Workload Identity-Föderation verwenden können, sind Terraform Cloud, GitHub und GitLab.
In diesem Dokument wird beschrieben, wie Sie Ihr Produkt um die Unterstützung der Workload Identity-Föderation erweitern können. Außerdem werden Best Practices beschrieben, die Sie beachten sollten. In diesem Dokument wird davon ausgegangen, dass Sie mit der Workload Identity-Föderation und OpenID Connect vertraut sind.
Architektur
Mit der Workload Identity-Föderation soll die Notwendigkeit von Dienstkontoschlüsseln beseitigt werden, indem Ihre Kunden Ihr Produkt oder Ihren Dienst mit ihrer Google Cloud-Umgebung föderieren können. Ihre Kunden können dann über eine von Ihrem Produkt oder Dienst angegebene Identität auf ihre Google Cloud-Ressourcen zugreifen.
Damit Ihre Kunden die Workload Identity-Föderation verwenden können, muss Ihr Produkt oder Dienst einen Teil von OpenID Connect implementieren. Insbesondere müssen Sie Arbeitslasten erlauben, ein ID-Token abzurufen, das die folgenden Kriterien erfüllt:
- Das Token identifiziert die Arbeitslast in Ihrem Produkt oder Ihrer Plattform.
- Das Token identifiziert die Instanz, den Mandanten oder die Installation Ihres Produkts oder Ihrer Plattform.
- Das Token enthält eine kryptografische Signatur, mit der die Workload Identity-Föderation die Authentizität des Tokens überprüfen kann.
Voraussetzungen
Wenn Sie die Workload Identity-Föderation unterstützen möchten, müssen Sie dafür sorgen, dass Ihr Produkt oder Dienst die folgenden Anforderungen erfüllt:
Arbeitslasten haben Zugriff auf ein gültiges ID-Token.
Eine Arbeitslast muss während ihres gesamten Lebenszyklus Zugriff auf ein ID-Token haben, das die Identität der Arbeitslast bestätigt und den von OpenID Connect 1.0 definierten Anforderungen entspricht.
Da ID-Tokens eine begrenzte Lebensdauer haben, müssen Sie dafür sorgen, dass ein ID-Token entweder seine Arbeitslast überdauert oder dass Arbeitslasten regelmäßig neue ID-Tokens erhalten können.
ID-Tokens identifizieren die Arbeitslast eindeutig.
Das ID-Token muss mindestens einen Anspruch enthalten, der die Arbeitslast eindeutig identifiziert. Die Arbeitslast-ID muss unveränderlich sein.
Bei Produkten oder Diensten, die die Mehrfachinstanzfähigkeit unterstützen, muss das Token außerdem mindestens einen Anspruch enthalten, der den Tenant eindeutig identifiziert. Die Mandanten-ID muss außerdem unveränderlich sein.
ID-Tokens sind signiert, aber nicht verschlüsselt.
Die Metadaten von OpenID-Anbietern sind öffentlich zugänglich und können aus ID-Tokens ermittelt werden.
Sie müssen ein OpenID-Anbieterkonfigurationsdokument an einem öffentlich zugänglichen Endpunkt bereitstellen, der mit dem OpenID-Aussteller-Discovery-Protokoll gefunden werden kann. Wenn ID-Tokens beispielsweise eine
iss-Anforderung mit dem Werthttps://service.example.com/v1/enthalten, müssen Sie ein OpenID-Anbieterkonfigurationsdokument aufhttps://service.example.com/v1/.well-known/openid-configurationangeben und der Endpunkt muss öffentlich über das Internet von jeder IP-Adresse aus zugänglich sein.Signaturschlüssel sind öffentlich zugänglich und können aus den Metadaten des OpenID-Anbieters ermittelt werden.
Sie müssen ein JSON Web Key Set (JWKS)-Dokument an einem öffentlich zugänglichen Endpunkt bereitstellen, das über das Feld
jwks_uriin den OpenID-Anbietermetadaten gefunden werden kann.
Best Practices
Beachten Sie die folgenden Best Practices, wenn Sie Ihr Produkt oder Ihren Dienst um die Unterstützung der Workload Identity-Föderation erweitern.
Best Practices:
Unterschied zwischen Identitäts- und ZugriffstokensID-Tokens so freigeben, dass sie mit Clientbibliotheken kompatibel sind
Verwenden Sie mandantenspezifische Aussteller-URLs.
Lassen Sie Nutzer die Zielgruppe des ID-Tokens angeben.
Unveränderliche, nicht wiederverwendbare Kennungen in ID-Token-Ansprüchen verwenden.
Kontextinformationen in ID-Tokens einschließen
Lebensdauer des ID-Tokens auf 60 Minuten begrenzen.
Unterschied zwischen Identitäts- und Zugriffstokens
Im Kontext der Workload Identity-Föderation dient ein ID-Token dazu, die Identität der Arbeitslast zu bestätigen: Das Token muss genügend Informationen enthalten, damit die Workload Identity-Föderation die Arbeitslast identifizieren und von anderen Arbeitslasten unterscheiden kann.
Im Gegensatz zu ID-Tokens dienen Zugriffstokens in der Regel einem anderen Zweck: Sie werden für Zugriffsentscheidungen verwendet und können Informationen dazu enthalten, welche Berechtigungen eine Arbeitslast hat oder auf welche APIs sie zugreifen darf.
Wenn Ihr Produkt oder Dienst Zugriffstokens für Zwecke wie den Aufruf der API Ihres Produkts durch Arbeitslasten verwendet, sind diese Zugriffstokens möglicherweise nicht für die Workload Identity-Föderation geeignet. Anstatt Zugriffstokens als ID-Tokens zu verwenden, sollten Sie einen zweiten Tokentyp einführen, der der Definition eines ID-Tokens entspricht. Arbeitslasten können dann das ID-Token für die Workload Identity-Föderation verwenden.
ID-Tokens so freigeben, dass sie mit Clientbibliotheken kompatibel sind
Die Google Cloud-Clientbibliotheken können ID-Tokens automatisch aus mehreren Quellen abrufen, darunter:
- HTTP-Endpunkt (URL-basierte Anmeldedaten)
- Lokale Datei (Dateibasierte Anmeldedaten)
Wenn Ihre Kunden ID-Tokens aus anderen Quellen abrufen möchten, müssen sie möglicherweise ihren Code ändern oder zusätzliche Tools oder Bibliotheken bereitstellen. Wenn Sie ID-Tokens auf eine Weise freigeben, die mit Clientbibliotheken kompatibel ist, können Sie diese zusätzlichen Komplexitäten vermeiden und es Ihren Kunden erleichtern, die Workload Identity-Föderation zu verwenden.
Mandantenspezifische Aussteller-URLs verwenden
Die im ID-Token einer Arbeitslast eingebetteten Berechtigungen sind möglicherweise innerhalb einer bestimmten Instanz Ihres Produkts oder Dienstes eindeutig, aber nicht für mehrere Instanzen Ihres Produkts oder Dienstes. Beispiel: Zwei Ihrer Kunden verwenden Ihr Produkt oder Ihren Dienst, um eine Arbeitslast bereitzustellen, und weisen diesen Arbeitslasten versehentlich denselben Namen und dieselbe ID zu.
Die Workload Identity-Föderation versucht, diese mögliche mangelnde Eindeutigkeit zu kompensieren. Prüfen Sie dazu die Aussteller-URL (iss) der ID-Tokens und lassen Sie nur Tokens eines einzelnen Ausstellers pro Workload Identity-Pool zu.
Wenn Ihr Produkt oder Dienst die Mehrinstanzfähigkeit unterstützt, teilen sich möglicherweise mehrere Kunden eine einzelne Instanz Ihres Produkts oder Dienstes und die ID-Tokens ihrer Arbeitslasten verwenden dieselbe Aussteller-URL. Wenn Sie dieselbe Aussteller-URL für mehrere Tenants verwenden, können Ihre Kunden von Spoofing-Angriffen betroffen sein: So kann ein Angreifer beispielsweise eine Arbeitslast in seinem eigenen Tenant erstellen, ihr dieselbe ID oder denselben Namen wie einer Arbeitslast im Tenant des Opfers zuweisen und das ID-Token seiner Arbeitslast verwenden, um die Identität der Arbeitslast des Opfers zu fälschen.
Verwenden Sie zum Schutz Ihrer Kunden vor Spoofing-Angriffen nicht dieselben Aussteller-URLs für mehrere Tenants und fügen Sie eine eindeutige Tenant-ID in die Aussteller-URL ein, z. B. https://saas.example.com/tenant-123/.
Nutzern erlauben, die Zielgruppe für das ID-Token anzugeben
Einige Arbeitslasten Ihrer Kunden müssen möglicherweise auf Google Cloud und andere Drittanbieterdienste zugreifen. Wenn Kunden Ihr Produkt oder Ihren Dienst mit mehreren vertrauenden Seiten föderieren, kann es vorkommen, dass das ID-Token einer Arbeitslast versehentlich oder böswillig für die falsche vertrauende Seite verwendet wird. Ein böswilliger Akteur könnte beispielsweise eine Arbeitslast dazu bringen, ein ID-Token preiszugeben, das für einen Drittanbieterdienst bestimmt war, und dieses ID-Token dann für die Workload Identity-Föderation verwenden.
Um zu verhindern, dass Ihre Kunden Opfer solcher Confused Deputy-Angriffe werden, sollten Sie in ID-Tokens keine statische Zielgruppe (aud-Anspruch) verwenden. Lassen Sie stattdessen Arbeitslasten eine Zielgruppe angeben, wenn sie ein ID-Token abrufen, und verwalten Sie optional eine Zulassungsliste für Zielgruppen, die Arbeitslasten anfordern können.
Standardmäßig erwartet die Workload Identity-Föderation, dass die Zielgruppe eines ID-Tokens mit der URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID übereinstimmt.
Achten Sie darauf, dass Arbeitslasten eine URL als Zielgruppe für ID-Tokens verwenden können und dass die Länge der Zielgruppen-URL weniger als 180 Zeichen beträgt.
Unveränderliche, nicht wiederverwendbare Kennungen in ID-Token-Ansprüchen verwenden
Wenn Kunden einer ihrer Arbeitslasten Zugriff auf Google Cloud-Ressourcen gewähren möchten, müssen sie eine IAM-Bindung erstellen, die auf die Identität der Arbeitslast durch Subjekt, Gruppe oder benutzerdefiniertes Attribut verweist. Das Subjekt, die Gruppe und die benutzerdefinierten Attribute der Identität der Arbeitslast werden aus den Ansprüchen im Identitätstoken der Arbeitslast abgeleitet.
Wenn ein Kunde eine IAM-Bindung erstellt, die sich auf einen mutable-Anspruch bezieht, verliert seine Arbeitslast möglicherweise versehentlich den Zugriff, wenn sich der Wert des Anspruchs ändert. Ein Kunde kann beispielsweise eine IAM-Bindung erstellen, die auf den Namen seiner Arbeitslast verweist. Wenn der Kunde die Arbeitslast später umbenennt, gilt die IAM-Bindung möglicherweise nicht mehr.
Schlimmer noch: Böswillige Akteure könnten versuchen, nicht autorisierten Zugriff auf andere Ressourcen zu erhalten, indem sie Arbeitslasten absichtlich umbenennen oder die Umgebung einer Arbeitslast so ändern, dass die Identität einer anderen Arbeitslast vorgetäuscht wird.
Damit Kunden solche Spoofing-Probleme vermeiden können, müssen ID-Tokens Kennungen enthalten, die unveränderlich sind und nicht wiederverwendet werden können.
Kontextinformationen in ID-Tokens einschließen
Anstatt Arbeitslasten einen uneingeschränkten Zugriff auf Google Cloud-Ressourcen zu gewähren, können Kunden den Zugriff so einschränken, dass eine Arbeitslast nur dann Google-Anmeldedaten abrufen kann, wenn bestimmte zusätzliche Kriterien erfüllt sind.
Damit Kunden solche Einschränkungen konfigurieren können, fügen Sie dem ID-Token zusätzliche Ansprüche mit Kontextinformationen hinzu. Beispiele für Kontextinformationen:
- Informationen zum Nutzer, der Inhaber der Arbeitslast ist oder sie gestartet hat
- den Grund und die Art und Weise, wie die Arbeitslast gestartet wurde
- die Anfrage, die derzeit von der Arbeitslast verarbeitet wird
Kunden können diese Ansprüche zum Konfigurieren von Attributbedingungen oder in Hauptidentitäten verwenden.
Lebensdauer des ID-Tokens auf 60 Minuten begrenzen
ID-Tokens haben eine begrenzte Lebensdauer, die durch den Anspruch exp bestimmt wird. Wenn eine Arbeitslast ein ID-Token für einen Token-Austausch verwendet, validiert die Workload Identity-Föderation den exp-Anspruch des ID-Tokens und stellt ein STS-Token aus, das so lange gültig ist wie das Eingabetoken, jedoch maximal eine Stunde.
Die Verwendung von ID-Tokens, die länger als eine Stunde gültig sind, hat keine Auswirkungen auf die Identitätsföderation von Arbeitslasten, kann aber das Risiko erhöhen, dass ein ID-Token versehentlich weitergegeben wird. Eine Lebensdauer von deutlich unter einer Stunde kann dazu beitragen, solche Risiken zu reduzieren, aber zu häufigen Token-Austauschen und einer geringeren Leistung führen.
Nächste Schritte
- Weitere Informationen zur Workload Identity-Föderation
- Best Practices für die Verwendung der Workload Identity-Föderation