Workload Identity-Föderation

Mit der Workload Identity-Föderation können Sie lokalen oder Multi-Cloud-Arbeitslasten Zugriff auf Ressourcen von Google Cloud gewähren. Dazu verwenden Sie föderierte Identitäten anstelle von Dienstkontoschlüsseln.

Sie können die Föderation für Dienste und Pipelines konfigurieren, die Folgendes tun:

Warum Workload Identity-Föderation?

Anwendungen, die außerhalb von Google Cloud ausgeführt werden, können Dienstkontoschlüssel für den Zugriff auf Ressourcen von Google Cloud verwenden. Dienstkontoschlüssel sind jedoch leistungsstarke Anmeldedaten und können ein Sicherheitsrisiko darstellen, wenn sie nicht ordnungsgemäß verwaltet werden. Die Identitätsföderation von Arbeitslasten eliminiert den mit Dienstkontoschlüsseln verbundenen Wartungs- und Sicherheitsaufwand.

Mit der Workload Identity-Föderation können Sie Hauptkonten, die auf föderierten Identitäten in einem Workload Identity-Pool basieren, mithilfe von Identity and Access Management (IAM) IAM-Rollen zuweisen. Sie können den Hauptkonten Zugriff auf bestimmte Google Cloud -Ressourcen gewähren. Dieser Ansatz wird als direkter Zugriff bezeichnet. Alternativ können Sie einem Dienstkonto Zugriff gewähren, das dann auf Ressourcen von Google Cloud zugreifen kann. Dieser Ansatz wird als Identitätsübernahme des Dienstkontos bezeichnet.

Identitätspools für Arbeitslasten

Ein Workload Identity-Pool ist eine Entität, mit der Sie externe Identitäten verwalten können.

Im Allgemeinen empfehlen wir, für jede Umgebung, die nicht Teil vonGoogle Cloudist und auf Google Cloud -Ressourcen zugreifen muss, beispielsweise Entwicklungs-, Staging- oder Produktionsumgebungen, einen neuen Pool zu erstellen.

Anbieter von Workload Identity-Pools:

Ein Workload Identity-Pool-Anbieter ist eine Entität, die eine Beziehung zwischen Google Cloud und Ihrem IdP beschreibt. Dazu gehören:

  • AWS
  • Microsoft Entra ID
  • GitHub
  • GitLab
  • Kubernetes-Cluster
  • Okta
  • Lokale Active Directory Federation Services (AD FS)
  • Terraform

Die Workload Identity-Föderation entspricht der Spezifikation des OAuth 2.0-Tokenaustauschs. Sie geben Anmeldedaten von Ihrem Identitätsanbieter an den Security Token Service weiter, der die Identität der Anmeldedaten prüft und dann ein föderiertes Token zurückgibt.

OIDC-Anbieter mit lokalen JWKs

Für eine Föderation von Arbeitslasten ohne öffentlichen OIDC-Endpunkt können Sie OIDC-JSON-Webschlüsselsätze (JWKS) direkt in den Pool hochladen. Dies ist häufig nötig, wenn Terraform oder GitHub Enterprise in Ihrer eigenen Umgebung gehostet wird oder regulatorische Vorgaben bestehen, öffentliche URLs nicht offenzulegen. Weitere Informationen finden Sie unter OIDC-JWKs verwalten (optional).

Attributzuordnungen

Die von Ihrem externen IdP ausgestellten Tokens enthalten ein oder mehrere Attribute. Einige IdPs bezeichnen diese Attribute als Anforderungen.

Google Security Token Service-Tokens enthalten außerdem ein oder mehrere Attribute, wie in der folgenden Tabelle aufgeführt:

Attribut Beschreibung
google.subject Erforderlich. Eine eindeutige Kennung für den Nutzer. Dieses Attribut wird in IAM-Rollenbindungen vom Typ principal:// verwendet und in Cloud Logging-Logs angezeigt. Der Wert muss eindeutig sein und darf 127 Zeichen nicht überschreiten.
google.groups Optional. Eine Reihe von Gruppen, zu denen die Identität gehört. Dieses Attribut wird in IAM-Rollenbindungen vom Typ principalSet:// verwendet, um allen Mitgliedern einer Gruppe Zugriff zu gewähren.
attribute.NAME Optional. Sie können bis zu 50 benutzerdefinierte Attribute definieren und diese Attribute in IAM-principalSet://-Rollenbindungen verwenden, um Zugriff auf alle Identitäten mit einem bestimmten Attribut zu gewähren.

Mit einer Attributzuordnung wird definiert, wie der Wert des Attributs des Google Security Token Service-Tokens von einem externen Token abgeleitet wird. Für jedes Attribut eines Google Security Token Service-Tokens können Sie eine Attributzuordnung definieren, die so formatiert ist:

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

Ersetzen Sie Folgendes:

  • TARGET_ATTRIBUTE ist ein Attribut des Google Security Token Service-Tokens.
  • SOURCE_EXPRESSION ist ein Ausdruck (Common Expression Language, CEL), der ein oder mehrere Attribute aus den von Ihrem externen Identitätsanbieter ausgegebenen Tokens transformiert.

Die folgende Liste enthält Beispiele für die Attributzuordnung:

  • Weisen Sie das Assertion-Attribut sub google.subject zu:

    google.subject=assertion.sub

  • Verketten Sie mehrere Assertion-Attribute:

    google.subject='myprovider::' + assertion.aud + '::' + assertion.sub

  • Ordnen Sie einem GUID-Wert-Assertion-Attribut workload_id einen Namen zu und weisen Sie das Ergebnis einem benutzerdefinierten Attribut namens attribute.my_display_name zu:

    attribute.my_display_name={
  "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
  "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
}[assertion.workload_id]

  • Verwenden Sie die logischen Operatoren und Funktionen von CEL, um ein benutzerdefiniertes Attribut namens attribute.environment je nach Amazon-Ressourcenname (ARN) entweder auf prod oder test festzulegen:

    attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"

  • Verwenden Sie die Funktion extract, um ein benutzerdefiniertes Attribut aws_role mit dem Namen der angenommenen Rolle oder, falls keine Rolle angenommen wurde, mit dem ARN der Identität zu füllen.

    attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

  • Verwenden Sie die split-Funktion, um einen String mit einem angegebenen Trennzeichen aufzuteilen. 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]

  • Verwenden Sie die join-Funktion, um eine Liste von Strings mit einem angegebenen Trennzeichen zu verbinden. 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(".")

Wenn Sie X.509-Clientzertifikate verwenden, ordnet die Workload Identity-Föderation google.subject standardmäßig dem allgemeinen Namen des Clientzertifikats (assertion.subject.dn.cn) zu:

google.subject=assertion.subject.dn.cn

Sie können auch zusätzliche Attribute aus den Blatt- und Zwischenzertifikaten zuordnen.

Wenn Sie für AWS keine Attributzuordnung angeben, wendet Google die folgende Standardzuordnung an, die die gängigsten Szenarien abdeckt:

google.subject=assertion.arn
attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

Bei dieser Zuordnung wird google.subject auf den ARN des Aufrufers und attribute.aws_role auf den ARN der angenommenen Rolle (ohne den Sitzungsnamen) gesetzt, wenn eine Rolle angenommen wird, oder andernfalls auf den ARN des Aufrufers. Sie können auch benutzerdefinierte Zuordnungen angeben.

Für OIDC- und SAML-Anbieter müssen Sie die Attributzuordnungen angeben. In der Dokumentation des Anbieters finden Sie eine Liste der Attribute zu seinen Anmeldedaten, damit Sie die Zuordnung erstellen können.

Weitere Informationen finden Sie in der API-Dokumentation zum Feld attributeMapping.

Attributbedingungen

Eine Attributbedingung ist ein CEL-Ausdruck, mit dem Assertion-Attribute und Zielattribute geprüft werden können. Wenn die Attributbedingung bei bestimmten Anmeldedaten als true ausgewertet wird, werden die Anmeldedaten akzeptiert. Andernfalls werden die Anmeldedaten abgelehnt.

Mit einer Attributbedingung können Sie einschränken, welche Identitäten sich über Ihren Workload Identity-Pool authentifizieren können.

Attributbedingungen sind in Szenarien wie den folgenden nützlich:

  • Wenn Ihre Arbeitslast einen Identitätsanbieter verwendet, der öffentlich verfügbar ist, können Sie den Zugriff so einschränken, dass nur die von Ihnen ausgewählten Identitäten Zugriff auf den Workload Identity-Pool haben.

  • Wenn Sie einen IdP mit mehreren Cloud-Plattformen verwenden, können Sie verhindern, dass Anmeldedaten, die für eine andere Plattform vorgesehen sind, für Google Cloudverwendet werden und umgekehrt. Dies trägt dazu bei, das Problem der Confused Deputy Attack zu vermeiden.

Die Attributbedingung für den Anbieter eines Workload Identity-Pools kann das Schlüsselwort assertion verwenden, das sich auf eine Zuordnung bezieht, die die vom Identitätsanbieter ausgestellten Authentifizierungsdaten darstellt. Sie können für den Zugriff auf die Werte der Zuordnung die Punktnotation verwenden. AWS-Anmeldedaten enthalten beispielsweise den Wert arn, auf den Sie als assertion.arn zugreifen können. Darüber hinaus kann die Attributbedingung jedes Attribut verwenden, das in der Attributzuordnung des Anbieters definiert ist.

Im folgenden Beispiel sind nur Anfragen von Identitäten mit einer bestimmten AWS-Rolle zulässig:

attribute.aws_role == "ROLE_MAPPING"

Weitere Informationen finden Sie in der API-Dokumentation zum Feld attributeCondition.

Zugriffsverwaltung

Der Token-Austausch gibt ein föderiertes Zugriffstoken zurück. Sie können dieses föderierte Zugriffstoken verwenden, um Ihrer Arbeitslast Zugriff im Namen von Hauptkontoidentitäten in Google Cloud -Ressourcen zu gewähren und ein kurzlebiges OAuth 2.0-Zugriffstoken abzurufen.

Sie können dieses Zugriffstoken verwenden, um IAM-Zugriff zu gewähren.

Wir empfehlen, die Workload Identity-Föderation zu verwenden, um Zugriff direkt auf eine Google Cloud -Ressource zu gewähren. Die meisten Google Cloud APIs unterstützen zwar die Workload Identity-Föderation, doch haben einige APIs Einschränkungen. Alternativ können Sie die Identitätsübernahme des Dienstkontos verwenden.

Mit diesem kurzlebigen Zugriffstoken können Sie alle Google Cloud -APIs aufrufen, auf die die Ressource oder das Dienstkonto Zugriff hat.

Direkter Ressourcenzugriff

Mit dem direkten Ressourcenzugriff können Sie Ihrer externen Identität mithilfe von ressourcenspezifischen Rollen direkt Zugriff auf eine Google Cloud -Ressource gewähren.

Alternative: Identitätsübernahme des Dienstkontos

Als Alternative zur Bereitstellung des direkten Ressourcenzugriffs können Sie die Identitätsübernahme des Dienstkontos verwenden.

Sie müssen Ihrem Dienstkonto die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) zuweisen.

Hauptkonten und Sicherheit

Mithilfe von Hauptkontotypen gewähren Sie Zugriff für Hauptkonten oder Teilmengen davon.

Hauptkontotypen

In der folgenden Tabelle wird beschrieben, wie Sie Hauptkonten als Einzelpersonen und Identitätsgruppen definieren:

Identitäten ID-Format
Eine Identität principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Alle Identitäten in einer Gruppe principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP_ID
Alle Identitäten mit einem bestimmten Attributwert principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE

Nächste Schritte