glpi-neural-brain/data/research-evidence/a4a4bd126a2a9fe5dc20e4cf.json

{
  "schema_version": 1,
  "saved_at": "2026-08-07T05:23:03.5364378Z",
  "content_sha256": "d5a7c70dbdab3d5ec6d414e360d62fc44e45b8b4aaf94835e7fe90d42cf80e04",
  "result": {
    "title": "Best Practices für die Verwendung der Identitätsföderation von Arbeitslasten  |  Identity and Access Management (IAM)  |  Google Cloud Documentation",
    "url": "https://docs.cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation?hl=de",
    "snippet": "Mit der Workload Identity-Föderation können Anwendungen, die außerhalb von Google Cloudausgeführt werden, die Identität eines Dienstkontos mithilfe von Anmeldedaten eines externen...",
    "content": "Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.\n\nHome\n\nDocumentation\n\nSecurity\n\nIAM\n\nIdentity and Access Management (IAM)\n\nLeitfäden\n\nFeedback geben\n\nBest Practices für die Verwendung der Identitätsföderation von Arbeitslasten\n\nMit Sammlungen den Überblick behalten\n\nSie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.\n\nMit der Workload Identity-Föderation können Anwendungen, die außerhalb von Google Cloudausgeführt werden, die Identität eines Dienstkontos mithilfe von Anmeldedaten eines externen Identitätsanbieters übernehmen.\n\nDie Workload Identity-Föderation kann zur Verbesserung der Sicherheit beitragen, indem Anwendungen die Authentifizierungsmechanismen nutzen, die die externe Umgebung bereitstellt, und Dienstkontoschlüssel können ersetzt werden .\n\nWenn Sie eine Workload Identity-Föderation sicher verwenden möchten, müssen Sie sie so konfigurieren, dass Sie vor folgenden Bedrohungen geschützt sind:\n\nSpoofing :Ein böswilliger Akteur kann versuchen, die Identität eines anderen Nutzers zu fälschen, um unbefugten Zugriff auf Google Cloud Ressourcen zu erhalten.\n\nRechteausweitung: Ein böswilliger Akteur kann die Workload Identity-Föderation nutzen, um Zugriff auf Ressourcen zu erhalten, auf die er sonst keinen Zugriff hätte.\n\nNachweisbarkeit: Ein böswilliger Akteur kann seine Identität und Aktionen mithilfe von externen Anmeldedaten verbergen, die die Rückverfolgung der Aktionen zu ihm erschweren.\n\nSchädliche Anmeldedatenkonfigurationen :Ein böswilliger Akteur kann eine schädliche Anmeldedatenkonfiguration bereitstellen, um Ihre Sicherheitsmaßnahmen zu umgehen.\n\nIn diesem Leitfaden werden Best Practices für die Entscheidung vorgestellt, wann die Workload Identity-Föderation verwendet werden soll und wie Sie sie so konfigurieren, dass Risiken minimiert werden.\n\nWann sollte die Workload Identity-Föderation verwendet werden?\n\nBest Practices :\n\nWorkload Identity-Föderation für Anwendungen verwenden, die Zugriff auf Ambient-Anmeldedaten haben\nZusätzlichen Tokenaustausch verwenden, um Ambient-Anmeldedaten zu verwenden, die von der Workload Identity-Föderation nicht unterstützt werden\n\nWorkload Identity-Föderation verwenden, um die Anzahl der Anmeldedaten zu reduzieren, die eine Rotation erfordern .\n\nWorkload Identity-Föderation für Anwendungen verwenden, die Zugriff auf Ambient-Anmeldedaten haben\n\nAnwendungen, die bei anderen Cloud-Anbietern als Google Cloud ausgeführt werden, haben häufig Zugriff auf Ambient-Anmeldedaten. Diese Anmeldedaten können von der Anwendung abgerufen werden, ohne dass eine zusätzliche Authentifizierung erforderlich ist. Hier einige Beispiele:\n\nIn AWS können in EC2 bereitgestellte Anwendungen Instanzprofile verwenden, um eine Rolle anzunehmen und temporäre Anmeldedaten zu erhalten.\n\nIn Azure können Anwendungen verwaltete Identitäten verwenden, um Zugriffstokens abzurufen.\n\nIn GitHub-Aktionen können Workflows ID-Tokens abrufen, die die Identität des Bereitstellungsjobs widerspiegeln.\n\nWenn die Ambient-Anmeldedaten OpenID Connect-Tokens (OIDC), SAML-Assertions oder AWS-Anmeldedaten sind, können Sie die Workload Identity-Föderation konfigurieren , damit Anwendungen diese Anmeldedaten gegen kurzlebige Google-Zugriffstokens austauschen können.\nWenn die Ambient-Anmeldedaten ein anderes Format haben, können Sie sie möglicherweise zuerst gegen ein OIDC-Token oder eine SAML-Assertion austauschen und dann für die Workload Identity-Föderation verwenden.\n\nVerwenden Sie die Workload Identity-Föderation, wenn eine Anwendung aufGoogle Cloud zugreifen muss und Zugriff auf Ambient-Anmeldedaten hat.\n\nZusätzlichen Tokenaustausch verwenden, um Ambient-Anmeldedaten zu verwenden, die von der Workload Identity-Föderation nicht unterstützt werden\n\nIn einigen Fällen kann eine Anwendung Zugriff auf Ambient-Anmeldedaten haben, die Arten von Anmeldedaten werden jedoch nicht von der Workload Identity-Föderation unterstützt. Prüfen Sie in diesen Fällen, ob Sie mit einem zusätzlichen Tokenaustausch die Ambient-Anmeldedaten in einen Anmeldedatentyp konvertieren können, den Sie für die Workload Identity-Föderation verwenden können.\n\nWenn Ihre Anwendung beispielsweise in einer Active Directory-Umgebung ausgeführt wird, hat sie möglicherweise Zugriff auf Kerberos-Anmeldedaten. Wenn Sie in Ihrer Umgebung einen Identitätsanbieter wie Active Directory Federation Services (AD FS) haben, der die integrierte Windows-Authentifizierung unterstützt, können Sie sich mit diesen Kerberos-Anmeldedaten beim Identitätsanbieter authentifizieren und ein OAuth-Zugriffstoken abrufen, das das JWT-Format verwendet. Mit diesem Zugriffstoken und der Workload Identity-Föderation können Sie die Anwendung dann einen zweiten Tokenaustausch durchführen lassen, um kurzlebige Google-Anmeldedaten abzurufen.\n\nDas Verketten von Tokenaustauschvorgängen erhöht die Komplexität und kann zusätzliche Abhängigkeiten mit sich bringen. Sie müssen jedoch keine Dienstkontoschlüssel verwalten und sichern.\n\nWorkload Identity-Föderation verwenden, um die Anzahl der Anmeldedaten zu reduzieren, die eine Rotation erfordern\n\nAnwendungen, die in einen OpenID- oder SAML-Identitätsanbieter eingebunden sind, verwenden häufig einen Clientschlüssel (oder eine andere Form von Secret), um sich beim Identitätsanbieter zu authentifizieren.\nIn der Regel wird dieses Secret als Teil der Anwendungskonfiguration gespeichert.\nWenn Sie eine solche Anwendung auf Google Cloudzugreifen lassen möchten, müssen Sie sich zwischen Folgendem entscheiden:\n\nDienstkontoschlüssel erstellen und zusammen mit dem anderen Secret speichern\n\nVom vorhandenen Identitätsanbieter ausgestellte Tokens verwenden und mithilfe der Workload Identity-Föderation gegen Google-Anmeldedaten austauschen\n\nDie erste Option erfordert zwei Secrets, aber die zweite Option benötigt nur eins.\nWenn Sie die Anzahl der Secrets reduzieren, können Sie die Secret-Rotation vereinfachen, was wiederum die Sicherheit verbessern kann.\n\nWorkload Identity-Föderation mit regionalen Endpunkten verwenden, um Datenstandortanforderungen zu erfüllen\n\nWenn Sie Anforderungen an den Datenstandort haben und die Region steuern müssen, in der Tokenaustausch stattfinden kann, konfigurieren Sie Ihre Arbeitslasten so, dass sie einen regionalen Endpunkt des Secure Token Service (STS) verwenden.\n\nWenn Sie eine Konfigurationsdatei für Anmeldedaten generieren möchten, die einen regionalen STS-Endpunkt verwendet, verwenden Sie den Befehl gcloud iam workload-identity create-cred-config und fügen Sie das Argument --sts-location= REGION hinzu.\n\nSo aktualisieren Sie eine vorhandene Konfigurationsdatei für Anmeldedaten:\n\nÖffnen Sie die Konfigurationsdatei mit Anmeldedaten.\n\nErsetzen Sie im Feld token_url https://sts.googleapis.com durch https://sts. REGION .rep.googleapis.com .\n\nInformationen zur Verwendung regionaler Endpunkte über Private Service Connect finden Sie unter Zugriff auf regionale Endpunkte über Private Service Connect-Endpunkte .\n\nSchutz vor Spoofing-Bedrohungen\n\nEin Workload Identity-Pool enthält keine Identitäten oder Nutzerkonten und unterscheidet sich dadurch von einem Nutzerverzeichnis wie Cloud Identity. Stattdessen stellt ein Workload Identity-Pool eine Ansicht dar, die Identitäten von externen Identitätsanbietern anzeigt, damit sie als IAM-Hauptkonten verwendet werden können.\n\nJe nachdem, wie Sie den Workload Identity-Pool und seine Anbieter konfigurieren, kann dieselbe externe Identität als mehrere verschiedene IAM-Hauptkonten dargestellt werden oder mehrere externe Identitäten können demselben IAM-Hauptkonto zugeordnet werden. Solche Mehrdeutigkeiten können dazu führen, dass böswillige Nutzer Spoofing-Angriffe starten können.\n\nIm folgenden Abschnitt werden Best Practices beschrieben, mit denen Sie mehrdeutige Zuordnungen vermeiden und das Risiko von Spoofing-Bedrohungen reduzieren können.\n\nBest Practices :\n\nAttributbedingungen bei der Föderation mit GitHub oder anderen Identitätsanbietern mit mehreren Mandanten verwenden\n\nDediziertes Projekt zum Verwalten von Workload Identity-Pools und -Anbietern verwenden .\n\nErstellen von Workload Identity-Poolanbietern in anderen Projekten mithilfe von Einschränkungen für Organisationsrichtlinien deaktivieren .\n\nEinzelnen Anbieter pro Workload Identity-Pool verwenden, um Themenkonflikte zu vermeiden\n\nZweimalige Föderation mit dem selben Identitätsanbieter vermeiden\n\nOIDC-Metadaten-Endpunkt Ihres Identitätsanbieters schützen\n\nURL des Workload Identity-Poolanbieters als Zielgruppe verwenden\n\nUnveränderliche Attribute in Attributzuordnungen verwenden\n\nNicht wiederverwendbare Attribute in Attributzuordnungen verwenden\n\nNicht zulassen, dass Attributzuordnungen geändert werden\n\nNicht auf Attribute verlassen, die nicht stabil oder zuverlässig sind\n\nAnmeldedatenkonfigurationen aus einer externen Quelle validieren, bevor sie zur Authentifizierung bei Google-APIs verwendet werden .\n\nAttributbedingungen bei der Föderation mit GitHub oder anderen Multi-Tenant-Identitätsanbietern verwenden\n\nDie Workload Identity-Föderation verwaltet kein Verzeichnis mit Nutzerkonten, sondern implementiert stattdessen anforderungsbasierte Identitäten : Wenn also zwei Tokens vom selben Identitätsanbieter (Identity Provider, IdP) ausgegeben werden und ihre Anforderungen demselben google.subject -Wert zugeordnet sind, wird davon ausgegangen, dass die beiden Tokens denselben Nutzer identifizieren.\nDie Workload Identity-Föderation prüft und verifiziert die Aussteller-URL des Tokens, um herauszufinden, welcher IdP ein Token ausgestellt hat.\n\nEinige Anbieter wie GitHub und Terraform Cloud verwenden für alle ihre Mandanten 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.\n\nWenn Sie diese Identitätsanbieter verwenden, reicht es nicht aus, dass die Workload Identity-Föderation die Aussteller-URL eines Tokens prüfen kann, um sicherzugehen, dass sie von einer vertrauenswürdigen Quelle stammt und dass seine Anforderungen vertrauenswürdig sind. Wir empfehlen, eine Attributbedingung für die Workload Identity-Föderation zu konfigurieren, um zu prüfen, ob das Token von einem vertrauenswürdigen Mandanten oder, im Fall von GitHub oder Terraform Cloud, von einer vertrauenswürdigen Organisation stammt.\n\nWeitere Informationen finden Sie unter Attributbedingung konfigurieren .\n\nDediziertes Projekt zum Verwalten von Workload Identity-Pools und -Anbietern verwenden\n\nAnstatt Workload Identity-Pools und -Anbieter über mehrere Projekte hinweg zu verwalten, verwenden Sie ein einzelnes, dediziertes Projekt, um Workload Identity-Pools und -Anbieter zu verwalten.\nEin dediziertes Projekt hilft bei Folgendem:\n\nDafür sorgen, dass nur vertrauenswürdige Identitätsanbieter für die Workload Identity-Föderation verwendet werden\n\nZugriff auf die Konfiguration von Workload Identity-Pools und -Anbietern zentral steuern\n\nKonsistente Attributzuordnungen und Bedingungen auf alle Projekte und Anwendungen anwenden\n\nSie können Einschränkungen für Organisationsrichtlinien verwenden, um die Verwendung eines dedizierten Projekts zur Verwaltung von Workload Identity-Pools und -Anbietern zu erzwingen.\n\nErstellen von Workload Identity-Poolanbietern in anderen Projekten mithilfe von Einschränkungen für Organisationsrichtlinien deaktivieren\n\nNutzer mit der Berechtigung zum Erstellen von Workload Identity-Poolanbietern können Workload Identity-Pools und -Anbieter erstellen, die für die von Ihnen in einem dedizierten Projekt verwalteten redundant sein können.\n\nSie können das Erstellen neuer Workload Identity-Poolanbieter verhindern, indem Sie die Organisationsrichtlinieneinschränkung constraints/iam.workloadIdentityPoolProviders mit einer Regel verwenden, die auf Alle ablehnen gesetzt ist.\n\nWenden Sie diese Einschränkungen im Stammverzeichnis Ihrer Organisationshierarchie an , um die Erstellung neuer Workload Identity-Poolanbieter standardmäßig zu verweigern. Erstellen Sie Ausnahmen für die Projekte, in denen Sie die Verwaltung von Workload Identity-Pools und -Anbietern zulassen möchten. Wenden Sie dazu eine Richtlinieneinschränkung an, die bestimmte, vertrauenswürdige AWS-Konten oder OIDC-Anbieter zulässt.\n\nEinzelnen Anbieter pro Workload Identity-Pool verwenden, um Themenkonflikte zu vermeiden\n\nMit der Workload Identity-Föderation können Sie mehr als einen Anbieter pro Workload Identity-Pool erstellen. Die Verwendung mehrerer Anbieter kann nützlich sein, wenn Identitäten von mehreren Anbietern verwaltet werden, Sie diese Komplexität aber vor Arbeitslasten, die in Google Cloudausgeführt werden, verbergen möchten.\n\nDie Verwendung mehrerer Anbieter birgt das Risiko von Themenkonflikten, bei denen die Attributzuordnung für google.subject eines Anbieters denselben Wert zurückgibt wie die Attributzuordnung für einen anderen Anbieter. Dies hat zur Folge, dass mehrere externe Identitäten demselben IAM-Hauptkonto zugeordnet werden. Dadurch sind die externen Identitäten in Cloud-Audit-Logs nicht mehr zu unterscheiden.\n\nVerwenden Sie einen einzigen Anbieter pro Workload Identity-Pool, um Themenkonflikte zu vermeiden.\nWenn Sie eine Föderation mit mehreren Anbietern einrichten müssen, erstellen Sie mehrere Workload Identity-Pools mit jeweils einem einzelnen Workload Identity-Anbieter.\n\nZweimalige Föderation mit dem selben Identitätsanbieter vermeiden\n\nSie können mehrmals eine Föderation mit demselben Identitätsanbieter einrichten, indem Sie mehrere Workload Identity-Poolanbieter erstellen, die dieselbe oder eine ähnliche Konfiguration verwenden.\nWenn diese Anbieter zum selben Workload Identity-Pool gehören, kann eine solche Konfiguration zu Themenkonflikten führen.\nWenn die Anbieter zu verschiedenen Workload Identity-Pools gehören, können keine Themenkonflikte auftreten. Stattdessen wird dieselbe externe Identität als unterschiedliche IAM-Hauptkonten dargestellt.\n\nDie Zuordnung einer ein",
    "content_type": "text/html",
    "query": "Wie wird Workload Identity in GCP Cloud Storage konfiguriert, um Zugriff auf Speicherobjekte zu steuern?",
    "language": "de-DE",
    "round": 3,
    "fetched": true,
    "relevant": true,
    "relevance": 0.40727272727272723,
    "source_quality": "reputable_secondary",
    "source_quality_score": 0.736,
    "actionable": true,
    "covered_gap_ids": [
      "GAP-001"
    ],
    "assessment_reason": "Die Quelle beschreibt allgemeine Best Practices für Workload Identity-Föderation, aber sie behandelt nicht direkt die Konfiguration von Workload Identity in Cloud Storage. Sie bietet keine konkreten Schritte zur Einrichtung, was die Frage nicht vollständig beantwortet."
  }
}