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 Cloudbenö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, mithilfe der Workload Identity-Föderation auf ihre Google Cloud Ressourcen zuzugreifen. 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 Federation soll die Notwendigkeit von Dienstkontoschlüsseln beseitigt werden, indem Ihre Kunden Ihr Produkt oder Ihren Dienst mit ihrerGoogle Cloud -Umgebung föderieren können. Ihre Kunden können dann über eine von Ihrem Produkt oder Dienst angegebene Identität auf ihreGoogle 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 anhand von 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 Kunden verwenden, kann das zu Spoofing-Angriffen führen: Ein Angreifer kann beispielsweise eine Arbeitslast in seinem eigenen Konto erstellen, ihr dieselbe ID oder denselben Namen wie einer Arbeitslast im Konto des Opfers zuweisen und das ID-Token seiner Arbeitslast verwenden, um die Identität der Arbeitslast des Opfers zu fälschen.
Um Ihre Kunden vor Spoofing-Angriffen zu schützen, sollten Sie nicht dieselbe Aussteller-URL für mehrere Mandanten verwenden. Außerdem sollten Sie eine eindeutige Mandanten-ID in die Aussteller-URL einbetten, 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 Cloudund 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 ein benutzerdefiniertes Attribut verweist. Das Subjekt, die Gruppe und die benutzerdefinierten Attribute der Identität der Arbeitslast werden aus den Ansprüchen im ID-Token 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 Nutzer die Arbeitslast anschließend 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