Identitätsföderation von Arbeitslasten

Dieses Dokument bietet eine Übersicht über die Identitätsföderation für externe Arbeitslasten. Mithilfe der Identitätsföderation können Sie lokalen oder Multi-Cloud-Arbeitslasten ohne Verwendung eines Dienstkontoschlüssels Zugriff auf Google Cloud-Ressourcen gewähren.

Sie können die Identitätsföderation mit Amazon Web Services (AWS) oder einem beliebigen anderen Identitätsanbieter nutzen, der OpenID Connect (OIDC) unterstützt, wie z. B. Microsoft Azure oder SAML 2.0.

Warum eine Identitätsföderation?

Traditionell können Anwendungen, die außerhalb von Google Cloud ausgeführt werden, Dienstkontoschlüssel für den Zugriff auf Google Cloud-Ressourcen verwenden. Dienstkontoschlüssel sind jedoch leistungsstarke Anmeldedaten und können ein Sicherheitsrisiko darstellen, wenn sie nicht ordnungsgemäß verwaltet werden.

Bei der Identitätsföderation können Sie externen Identitäten mithilfe der Identitäts- und Zugriffsverwaltung (IAM) IAM-Rollen zuweisen. Somit bietet sich auch die Möglichkeit, die Identität von Dienstkonten zu übernehmen. Bei diesem Ansatz entfallen die mit Dienstkontoschlüsseln verbundenen Wartungs- und Sicherheitsaufwand.

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 von Google Cloud ist 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 Identitätsanbieter beschreibt. Dazu gehören:

  • AWS
  • Azure Active Directory
  • Lokale Active Directory Federation Services (AD FS)
  • Okta
  • Kubernetes-Cluster

Die Identitätsföderation von Arbeitslasten entspricht der Spezifikation des OAuth 2.0-Tokenaustauschs. Sie geben Anmeldedaten von Ihrem Identitätsanbieter an das Sicherheits-Token-Dienst weiter, der die Identität auf den Anmeldedaten prüft und dann ein föderiertes Token zurückgibt.

OIDC-Anbieter-JWKs

Der Workload Identity-Poolanbieter kann auf JSON-Webschlüssel (JWKs) zugreifen, die von Ihrem Identitätsanbieter im Feld jwks_uri des Dokuments /.well-known/openid-configuration bereitgestellt werden. Wenn Ihr OIDC-Anbieter diese Informationen nicht bereitstellt, können Sie die JWKs beim Erstellen des Anbieters manuell hochladen.

Attributzuordnungen

Die von Ihrem externen Identitätsanbieter ausgestellten Tokens enthalten ein oder mehrere Attribute. Einige Identitätsanbieter bezeichnen diese Attribute als Ansprüche.

Google STS-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 Google STS-Tokenattributs von einem externen Token abgeleitet wird. Für jedes Google STS-Tokenattribut können Sie eine Attributzuordnung definieren, die so formatiert ist:

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

Dabei gilt:

  • TARGET_ATTRIBUTE ist ein Attribut des Google STS-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

  • Die split-Funktion teilt einen String mit dem angegebenen Trennzeichenwert auf. 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]

  • Die join-Funktion verbindet eine Liste von Strings im angegebenen Trennzeichenwert. 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(".")

Für AWS stellt Google Standardzuordnungen bereit, die die gängigsten Szenarien abdecken. Sie können auch benutzerdefinierte Zuordnungen bereitstellen.

Bei OIDC-Anbietern müssen Sie die Zuordnungen 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 Identitätspool der Arbeitslast haben.

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

Die Attributbedingung für einen Workload Identity-Poolanbieter 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.

Identitätsübertragung für ein Dienstkonto

Der Token-Austausch gibt ein föderiertes Zugriffstoken zurück. Sie können mit diesem Token die Identität eines Dienstkontos übernehmen und ein kurzlebiges OAuth 2.0-Zugriffstoken abrufen. Mit diesem Token können Sie alle Google Cloud APIs aufrufen, auf die das Dienstkonto Zugriff hat.

Um die Identität eines Dienstkontos zu übernehmen, weisen Sie der externen Identität die Rolle "Nutzer von Workload Identity" (roles/iam.workloadIdentityUser) für ein Dienstkonto zu, das die für die Arbeitslast erforderlichen Rollen hat. Sie können eine Rolle entweder allen Identitäten im Workload Identity-Pool einer Arbeitslast oder bestimmten externen Identitäten anhand ihrer Attribute zuweisen.

In der folgenden Tabelle sind häufig vorkommende Szenarien für das Zuweisen von Rollen beschrieben:

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
Alle Identitäten in einem Pool principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*

Nächste Schritte