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 Dienste:
- 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 lokalen oder SaaS-Produkts können Sie Ihre Kunden beim Schutz ihrer Google Cloud-Ressourcen unterstützen, indem Sie ihnen die Verwendung der Workload Identity-Föderation für den Zugriff auf ihre Google Cloud-Ressourcen erlauben. Beispiele für Dienste, mit denen ihre Kunden bereits eine Workload Identity-Föderation verwenden können, sind Terraform Cloud, GitHub und GitLab.
In diesem Artikel wird beschrieben, wie Sie Ihr Produkt zur Unterstützung der Workload Identity-Föderation erweitern können. Außerdem werden Best Practices beschrieben, denen Sie folgen können. Dabei wird davon ausgegangen, dass Sie mit der Workload Identity-Föderation und OpenID Connect vertraut sind.
Architektur
Der Zweck der Workload Identity-Föderation ist es, keine Dienstkontoschlüssel mehr zu benötigen, da Ihre Kunden Ihr Produkt oder Ihren Dienst mit ihrer Google Cloud-Umgebung verbinden können. Ihre Kunden können dann mit einer Identität, die Ihrem Produkt oder Dienst bestätigt wurde, auf ihre Google Cloud-Ressourcen zugreifen.
Damit Ihre Kunden die Workload Identity-Föderation verwenden können, muss Ihr Produkt oder Ihr Dienst eine Teilmenge von OpenID Connect implementieren. Insbesondere müssen Sie Arbeitslasten erlauben, ein ID-Token zu erhalten, 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
Zur Unterstützung der Workload Identity-Föderation müssen Sie dafür sorgen, dass Ihr Produkt oder Ihr Dienst die folgenden Anforderungen erfüllt:
Arbeitslasten haben Zugriff auf ein gültiges ID-Token.
Während ihres Lebenszyklus muss eine Arbeitslast jederzeit 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 eine Anforderung enthalten, die die Arbeitslast eindeutig identifiziert. Die Arbeitslastkennung muss unveränderlich sein.
Bei Produkten oder Diensten, die die Mehrinstanzenfähigkeit unterstützen, muss das Token mindestens eine Anforderung enthalten, die den Mandanten eindeutig identifiziert. Die Mandanten-ID muss ebenfalls unveränderlich sein.
ID-Tokens sind signiert, aber nicht verschlüsselt.
Metadaten des OpenID-Anbieters sind öffentlich zugänglich und können aus ID-Tokens ermittelt werden.
Sie müssen ein Konfigurationsdokument für OpenID-Anbieter auf einem öffentlich zugänglichen Endpunkt bereitstellen, der mit dem Protokoll zur Erkennung des OpenID-Ausstellers erkannt 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.Signierschlüssel sind öffentlich zugänglich und können in den Metadaten des OpenID-Anbieters ermittelt werden.
Sie müssen auf einem öffentlich zugänglichen Endpunkt ein JSON Web Key Set (JWKS)-Dokument bereitstellen, das im Feld
jwks_urider Metadaten des OpenID-Anbieters zu finden ist.
Best Practices
Beachten Sie die folgenden Best Practices, wenn Sie Ihr Produkt oder Ihren Dienst zur Unterstützung der Workload Identity-Föderation erweitern.
Best Practices:
Zwischen Identitäts- und Zugriffstokens unterscheiden.ID-Tokens so bereitstellen, dass sie mit Clientbibliotheken kompatibel sind
Mandantenspezifische Aussteller-URLs verwenden
Nutzern die Angabe der ID-Token-Zielgruppe erlauben
Unveränderliche, nicht wiederverwendbare Kennungen in Anforderungen von ID-Tokens verwenden
Kontextinformationen in ID-Tokens einfügen
Beschränken Sie die Lebensdauer des ID-Tokens auf 30 bis 60 Minuten.
Zwischen Identitäts- und Zugriffstokens unterscheiden
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 darüber enthalten, welche Berechtigungen eine Arbeitslast hat oder auf welche APIs sie zugreifen darf.
Wenn Ihr Produkt oder Dienst derzeit Zugriffstokens für andere Zwecke verwendet, damit Arbeitslasten die API Ihres Produkts aufrufen können, eignen sich diese Zugriffstokens möglicherweise nicht für die Workload Identity-Föderation. Anstatt Zugriffstokens als ID-Token wiederzuverwenden, sollten Sie einen zweiten Tokentyp einführen, der der Definition eines ID-Tokens entspricht, und Arbeitslasten das ID-Token für die Workload Identity-Föderation verwenden.
ID-Tokens so bereitstellen, dass sie mit Clientbibliotheken kompatibel sind
Die Google Cloud-Clientbibliotheken können automatisch ID-Tokens aus mehreren Quellen abrufen, darunter:
- Ein HTTP-Endpunkt (URL-basierte Anmeldedaten)
- Lokale Datei (dateibasierte Anmeldedaten)
Um ID-Tokens aus anderen Quellen zu erhalten, müssen Ihre Kunden möglicherweise ihren Code ändern oder zusätzliche Tools oder Bibliotheken bereitstellen. Wenn Sie ID-Tokens auf eine Weise bereitstellen, die mit Clientbibliotheken kompatibel ist, können Sie diese zusätzliche Komplexität vermeiden und Ihren Kunden den Umstieg auf die Workload Identity-Föderation erleichtern.
Mandantenspezifische Aussteller-URLs verwenden
Die Anforderungen, die in das ID-Token einer Arbeitslast eingebettet sind, können innerhalb einer bestimmten Instanz Ihres Produkts oder Dienstes eindeutig sein. Es kann jedoch vorkommen, dass sie nicht in mehreren Instanzen Ihres Produkts oder Dienstes vorkommen. Beispielsweise könnten zwei Ihrer Kunden mit Ihrem Produkt oder Dienst eine Arbeitslast bereitstellen und diese Arbeitslasten versehentlich denselben Namen und dieselbe ID zuweisen.
Die Workload Identity-Föderation versucht, diese mögliche 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 Ihre Mandantenfähigkeit unterstützt, verwenden möglicherweise mehrere Ihrer Kunden eine einzelne Instanz Ihres Produkts oder Dienstes und die ID-Tokens ihrer Arbeitslasten verwenden möglicherweise dieselbe Aussteller-URL. Wenn Sie dieselbe Aussteller-URL für mehrere Mandanten verwenden, können Ihre Kunden Spoofing-Angriffe erhalten: Ein böswilliger Akteur kann beispielsweise eine Arbeitslast in seinem eigenen Mandanten erstellen und ihm dieselbe ID oder denselben Namen wie eine Arbeitslast zuweisen. Mandanten des Mandanten und das ID-Token der Arbeitslast verwenden, um die Identität der Arbeitslast des betroffenen Nutzers zu manipulieren.
Zum Schutz Ihrer Kunden vor Spoofing-Angriffen sollten Sie nicht dieselben Aussteller-URLs auf mehrere Mandanten verwenden und eine eindeutige Mandanten-ID in die Aussteller-URL einbetten, z. B. https://saas.example.com/tenant-123/.
Nutzern erlauben, die Zielgruppe des ID-Tokens anzugeben
Einige Arbeitslasten Ihres Kunden müssen möglicherweise auf Google Cloud und andere Drittanbieterdienste zugreifen. Wenn Kunden Ihr Produkt oder Ihre Dienstleistung mit mehreren vertrauenden Parteien verbinden, kommt es möglicherweise zu einer Situation, in der das ID-Token einer Arbeitslast versehentlich oder für die falsche Partei verwendet wird: Beispiel: Ein böswilliger Akteur kann eine Arbeitslast dazu bringen, ein ID-Token aufzudecken, das für einen Drittanbieterdienst bestimmt war, und dieses ID-Token dann für die Workload Identity-Föderation verwenden.
Vermeiden Sie die Verwendung einer statischen Zielgruppe (aud-Anforderung) in ID-Tokens, um zu verhindern, dass Ihre Kunden einem solchen Confused-Deputy-Angriff ausgesetzt sind. Stattdessen können Arbeitslasten eine Zielgruppe angeben, wenn sie ein ID-Token abrufen, und optional eine Zulassungsliste für Zielgruppen verwalten, 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 Zielgruppen bis zu 180 Zeichen lang sein können.
Unveränderliche, nicht wiederverwendbare Kennungen in ID-Token-Anforderungen verwenden
Wenn Kunden einer ihrer Arbeitslasten Zugriff auf Google Cloud-Ressourcen gewähren möchten, müssen sie eine IAM-Bindung erstellen, die nach Thema, Gruppe oder benutzerdefiniertem Attribut auf die Identität der Arbeitslast verweist. Das Thema, die Gruppe und die benutzerdefinierten Attribute der Arbeitslast werden von den Anforderungen im ID-Token der Arbeitslast abgeleitet.
Wenn ein Kunde eine IAM-Bindung erstellt, die auf eine änderbare Anforderung verweist, kann seine Arbeitslast versehentlich den Zugriff verlieren, wenn sich der Wert der Anforderung ändert. Ein Kunde kann beispielsweise eine IAM-Bindung erstellen, die auf den Namen ihrer Arbeitslast verweist. Wenn sie die Arbeitslast anschließend umbenennen, gilt die IAM-Bindung möglicherweise nicht mehr.
Umso mehr sind böswillige Nutzer in der Lage, versuchen, nicht autorisierten Zugriff auf andere Ressourcen zu erhalten, indem sie Arbeitslasten umbenennen oder die Umgebung einer Arbeitslast ändern, um die Identität einer anderen Arbeitslast zu manipulieren.
Um Kunden dabei zu helfen, Spoofing-Probleme zu vermeiden, achten Sie darauf, dass ID-Tokens unveränderliche IDs enthalten, die nicht wiederverwendet werden können.
Kontextinformationen in ID-Tokens einfügen
Anstatt Arbeitslasten bedingungslosen Zugriff auf Google Cloud-Ressourcen zu gewähren, möchten Kunden möglicherweise 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, müssen Sie dem ID-Token zusätzliche Anforderungen hinzufügen, die Kontextinformationen enthalten. Beispiele für Kontextinformationen sind:
- Informationen zu dem Nutzer, der die Arbeitslast besitzt oder 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 Anforderungen verwenden, um Attributbedingungen oder Hauptkennzeichnungen zu konfigurieren.
Lebensdauer des ID-Tokens auf 60 Minuten begrenzen
ID-Tokens haben eine begrenzte Lebensdauer, die durch die Anforderung exp bestimmt wird. Wenn eine Arbeitslast ein ID-Token für einen Tokenaustausch verwendet, validiert die Workload Identity-Föderation die Anforderung exp des ID-Tokens und gibt ein STS-Token aus, das so lange gültig ist wie das Eingabetoken Höchstens eine Stunde lang.
Die Verwendung von ID-Tokens, die länger als eine Stunde gültig sind, hat keine Auswirkungen auf die Föderation von Workload Identity, kann jedoch die Risiken erhöhen, wenn ein ID-Token versehentlich gehackt wird. Eine Lebensdauer von deutlich weniger als einer Stunde kann dabei helfen, solche Risiken zu verringern, kann jedoch zu häufigen Tokenaustauschen führen und die Leistung beeinträchtigen.
Nächste Schritte
- Weitere Informationen zur Workload Identity-Föderation
- Best Practices für die Verwendung der Workload Identity-Föderation