Workload Identity-Föderation mit X.509-Zertifikaten konfigurieren

In diesem Leitfaden wird beschrieben, wie Sie die Workload Identity-Föderation mit X.509-Zertifikaten verwenden, die von Ihrer Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurden, um sich bei Google Cloud zu authentifizieren und auf Google Cloud-Ressourcen zuzugreifen.

Wenn Ihre Arbeitslasten ein mTLS-Clientzertifikat haben, können Sie sich bei Google Cloud authentifizieren, indem Sie eine oder mehrere Zertifizierungsstellen bei der Workload Identity-Föderation als Trust Anchors registrieren. Sie können auch Zwischenzertifizierungsstellen registrieren.

Mit der Workload Identity-Föderation können Sie diese Arbeitslasten kurzlebige Google Cloud-Anmeldedaten über eine gegenseitige TLS-Verbindung (mTLS) abrufen lassen. Arbeitslasten können mit diesen kurzlebigen Anmeldedaten auf Google Cloud APIs zugreifen.

Konzepte

Zu den X.509-Zertifikat-basierten Föderationskonzepten gehören:

  • Ein Vertrauensanker ist ein CA-Zertifikat, das als Vertrauensbasis gilt. Alle Clientzertifikatsketten sollten mit einem der Trustanchors verknüpft sein.

  • Ein Zwischenzertifikat ist ein optionales Zertifikat einer Zertifizierungsstelle, das beim Erstellen der Clientzertifikatskette hilft.

  • Ein Trust Store enthält die Trust Anchor-Zertifikate und Zwischen-CA-Zertifikate, die zum Validieren der Clientzertifikatskette verwendet werden. Eine Zertifizierungsstelle stellt vertrauenswürdige Zertifikate für den Client aus.

    Sie können die folgenden Arten von Clientzertifikaten in den Trust Store hochladen:

    • Von Drittanbieter-Zertifizierungsstellen Ihrer Wahl ausgestellte Zertifikate
    • Von Ihren privaten Zertifizierungsstellen ausgestellte Zertifikate
    • Signierte Zertifikate, wie unter Selbst signierte Zertifikate erstellen beschrieben

Hinweise

So konfigurieren Sie die Workload Identity-Föderation:

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

    2. Wir empfehlen, ein dediziertes Projekt zur Verwaltung von Workload Identity-Pools und -Anbietern.

  2. Make sure that billing is enabled for your Google Cloud project.

    3. Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

    Enable the APIs

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Konfigurieren der Workload Identity-Föderation benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Alternativ enthält die einfache Rolle „IAM-Inhaber“ (roles/owner) auch Berechtigungen zum Konfigurieren der Identitätsföderation. In einer Produktionsumgebung sollten Sie keine einfachen Rollen zuweisen, Sie können sie aber in einer Entwicklungs- oder Testumgebung gewähren.

Identitätsföderation von Arbeitslasten konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie die Workload Identity-Föderation und Ihren Vertrauensspeicher konfigurieren. Sie müssen diese Schritte nur einmal für jeden Truststore ausführen. Sie können dann denselben Workload Identity-Pool und -Anbieter für mehrere Arbeitslasten und mehrere Google Cloud-Projekte verwenden.

Vertrauensspeicher erstellen und konfigurieren

In diesem Abschnitt wird gezeigt, wie Sie eine YAML-Konfigurationsdatei für den Truststore und ein selbstsigniertes CA-Zertifikat erstellen.

Schlüssel und signierte Zertifikate generieren

In diesem Abschnitt werden openssl-Befehle verwendet, um Root- und Zwischenzertifikate zu erstellen.

Wenn Sie bereits Zertifikate haben, können Sie diesen Schritt überspringen und mit Zertifikate formatieren fortfahren.

So generieren Sie ein Root-Zertifikat und ein signiertes Zwischenzertifikat mit gültigen Feldern keyUsage und extendedKeyUsage:

  1. Erstellen Sie eine Beispieldatei vom Typ example.cnf mit der Mindestkonfiguration, die zum Erstellen gültiger Signaturzertifikate erforderlich ist. Sie können diese Datei bearbeiten, um zusätzliche Felder für diese Zertifikate festzulegen.

    cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name
[empty_distinguished_name]
# Kept empty to allow setting via -subj command line arg.
[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth
EOF

  2. Erstellen Sie das Root-Zertifikat:

    openssl req -x509 \
    -new -sha256 -newkey rsa:2048 -nodes \
    -days 3650 -subj '/CN=root' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout root.key -out root.cert

  3. Erstellen Sie die Signaturanfrage für das Zwischenzertifikat:

    openssl req \
    -new -sha256 -newkey rsa:2048 -nodes \
    -subj '/CN=int' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout int.key -out int.req

  4. Erstellen Sie das Zwischenzertifikat:

    openssl x509 -req \
    -CAkey root.key -CA root.cert \
    -set_serial 1 \
    -days 3650 \
    -extfile example.cnf \
    -extensions ca_exts \
    -in int.req -out int.cert

Zertifikate formatieren

Wenn Sie neue oder vorhandene Zertifikate in einen Trust Store aufnehmen möchten, formatieren Sie die Zertifikate in einer einzelnen Zeile und speichern Sie sie in Umgebungsvariablen, damit sie in die YAML-Datei gelesen werden können. Die Zertifikate müssen im PEM-Format vorliegen. So formatieren Sie die Zertifikate und speichern sie in Umgebungsvariablen:

  1. Speichern Sie das Root-Zertifikat als einzeiligen String:

    export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | sed -z '$ s/\n$//' | tr '\n' $ | sed 's/\$/\\n/g')

  2. Speichern Sie ein Zwischenzertifikat als einzeiligen String:

    export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | sed -z '$ s/\n$//' | tr '\n' $ | sed 's/\$/\\n/g')

YAML-Datei für den Truststore erstellen

In diesem Abschnitt erstellen Sie eine YAML-Datei für den Trust Store, die Ihre Trust-Anchors und Zwischen-CAs enthält.

Führen Sie den folgenden Befehl aus, um die YAML-Datei für den Trust Store zu erstellen. Diese Datei enthält den Zertifikatsinhalt aus den Umgebungsvariablen, die Sie unter Zertifikate formatieren erstellt haben. Wenn Sie weitere Vertrauensanker hinzufügen möchten, fügen Sie unter trustStore weitere trustAnchors-Einträge hinzu. Wenn Sie zusätzliche Zwischenzertifizierungsstellenzertifikate hinzufügen möchten, fügen Sie unter trustStore weitere intermediateCas-Einträge hinzu.

cat << EOF > trust_store.yaml
trustStore:
  trustAnchors:
  - pemCertificate: "${ROOT_CERT}"
  intermediateCas:
  - pemCertificate: "${INTERMEDIATE_CERT}"
EOF

Attributzuordnung und -bedingung definieren

Das X.509-Zertifikat des Clients kann mehrere Attribute enthalten. Sie müssen auswählen, welches Attribut Sie als Betreff-ID verwenden möchten. Ordnen Sie dazu google.subject in Google Cloud dem Attribut aus Ihrem Zertifikat zu. Wenn das Attribut im Zertifikat beispielsweise der gemeinsame Name des Subjekts ist, sieht die Zuordnung so aus: google.subject=assertion.subject.dn.cn

Optional können Sie zusätzliche Attribute zuordnen. Sie können dann auf diese Attribute verweisen, wenn Sie Zugriff auf Ressourcen gewähren.

Ihre Attributzuordnungen können die Attribute im Clientzertifikat verwenden, darunter:

  • serialNumberHex: die Seriennummer
  • subject.dn.cn: der gemeinsame Name des Subjekts
  • subject.dn.o: der Name der betreffenden Organisation
  • subject.dn.ou: die betreffende Organisationseinheit
  • issuer.dn.cn: der gemeinsame Name des Ausstellers
  • issuer.dn.o: der Name der Ausstellerorganisation
  • issuer.dn.ou: die Organisationseinheit des Ausstellers
  • san.dns: der erste DNS-Name des alternativen Antragstellernamens
  • san.uri: der erste URI des alternativen Namens des Subjekts

Sie müssen eine dieser Anforderungen google.subject zuordnen, um das Subjekt eindeutig zu identifizieren. Wählen Sie zum Schutz vor Spoofing-Bedrohungen ein Attribut mit einem eindeutigen Wert aus, der nicht geändert werden kann. Standardmäßig ist die google.subject-ID auf den allgemeinen Namen des Zertifikatsubjekts des Clientzertifikats, assertion.subject.dn.cn, festgelegt.

Optional: Definieren Sie eine Attributbedingung. Attributbedingungen sind CEL-Ausdrücke, die Assertion-Attribute und Zielattribute prüfen 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 Subjekte die Workload Identity-Föderation verwenden können, um kurzlebige Google Cloud-Tokens abzurufen.

Die folgende Bedingung schränkt beispielsweise den Zugriff auf Clientzertifikate mit der SPIFFE-ID spiffe://example/path ein:

assertion.san.uri=="spiffe://example/path"

Workload Identity-Pool und -Anbieter erstellen

  1. Führen Sie folgenden Befehl aus, um einen neuen Workload Identity-Pool zu erstellen:

    gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"

    Ersetzen Sie Folgendes:

    • POOL_ID: die eindeutige ID des Pools.
    • DISPLAY_NAME: der Name des Pools.
    • DESCRIPTION: eine Beschreibung des von Ihnen gewählten Pools. Diese Beschreibung wird angezeigt, wenn Sie Zugriff auf Poolidentitäten gewähren.

  2. Führen Sie folgenden Befehl aus, um einen X.509-Workload Identity-Pool-Anbieter hinzuzufügen:

    gcloud iam workload-identity-pools providers create-x509 PROVIDER_ID \
    --location=global \
    --workload-identity-pool="POOL_ID" \
    --trust-store-config-path="TRUST_STORE_CONFIG" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS" \
    --billing-project="ALLOWLISTED_PROJECT"

    Ersetzen Sie Folgendes:

    • PROVIDER_ID: eine eindeutige Anbieter-ID für Workload Identity-Pool Ihrer Wahl.
    • POOL_ID: die ID des Workload Identity-Pools, die Sie zuvor erstellt haben.
    • TRUST_STORE_CONFIG: Die YAML-Datei des Trust Stores.
    • MAPPINGS: eine durch Kommas getrennte Liste der Attributzuordnungen, die Sie zuvor in dieser Anleitung erstellt haben. Wenn Sie google.subject nicht angeben, wird die Standardzuordnung google.subject=assertion.subject.dn.cn verwendet.
    • CONDITIONS: eine optionale Attributbedingung, die Sie zuvor in dieser Anleitung erstellt haben. Entfernen Sie den Parameter, wenn keine Attributbedingung vorliegt.
    • ALLOWLISTED_PROJECT: die Projekt-ID

Arbeitslast authentifizieren

Sie müssen diese Schritte einmal für jede Arbeitslast ausführen.

Externer Arbeitslast Zugriff auf Google Cloud-Ressourcen gewähren

Damit Ihre Arbeitslast auf Google Cloud-Ressourcen zugreifen kann, empfehlen wir, dem Hauptkonto direkten Ressourcenzugriff zu gewähren. In diesem Fall ist das Hauptkonto der föderierte Nutzer. Für einige Google Cloud-Produkte gelten Einschränkungen der Google Cloud API. Wenn Ihre Arbeitslast einen API-Endpunkt aufruft, der eingeschränkt ist, können Sie stattdessen die Identitätsübernahme des Dienstkontos verwenden. In diesem Fall ist das Google Cloud-Dienstkonto das Hauptkonto, das als Identität dient. Sie gewähren dem Dienstkonto Zugriff auf die Ressource.

Direkter Ressourcenzugriff

Sie können einer föderierten Identität mithilfe der Google Cloud Console oder der gcloud CLI direkt Zugriff auf Ressourcen gewähren.

Console

Wenn Sie über die Google Cloud Console IAM-Rollen direkt für eine Ressource gewähren möchten, müssen Sie die Seite der Ressource aufrufen und die Rolle dann gewähren. Im folgenden Beispiel wird gezeigt, wie Sie die Seite „Cloud Storage“ aufrufen und einer föderierten Identität direkt in einem Cloud Storage-Bucket die Rolle „Storage-Objekt-Betrachter“ (roles/storage.objectViewer) gewähren.

  1. Wechseln Sie in der Cloud Console zur Seite Cloud Storage-Buckets.

    Buckets aufrufen

  2. Klicken Sie in der Liste der Buckets auf den Namen des Buckets, für den Sie die Rolle zuweisen möchten.

  3. Wählen Sie oben auf der Seite den Tab Berechtigungen aus.

  4. Klicken Sie auf die Schaltfläche Zugriff gewähren.

    Das Dialogfeld Hauptkonten hinzufügen wird angezeigt.

  5. Geben Sie in das Feld Neue Hauptkonten eine oder mehrere Identitäten ein, die Zugriff auf den Bucket erhalten sollen.

    Nach Subjekt 

    principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT

    Ersetzen Sie Folgendes:

    • PROJECT_NUMBER: die Projektnummer
    • POOL_ID: die ID des Arbeitslastpools
    • SUBJECT: das einzelne Thema, das Ihrem IdP zugeordnet ist, z. B. administrator@example.com

    Nach Gruppe 

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP

    Ersetzen Sie Folgendes:

    • PROJECT_NUMBER: die Projektnummer
    • WORKLOAD_POOL_ID: die ID des Arbeitslastpools
    • GROUP: die Gruppe, die Ihrem IdP zugeordnet ist, z. B.: administrator-group@example.com

    Nach Attribut 

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE

    Ersetzen Sie Folgendes:

    • PROJECT_NUMBER: die Projektnummer
    • WORKLOAD_POOL_ID: die ID des Arbeitslastpools
    • ATTRIBUTE_NAME: eines der Attribute, die von Ihrem IdP zugeordnet wurden.
    • ATTRIBUTE_VALUE: der Wert des Attributs

  6. Wählen Sie aus dem Drop-down-Menü Rolle auswählen eine oder mehrere Rollen aus. Die ausgewählten Rollen werden in der Ansicht mit einer kurzen Beschreibung ihrer jeweiligen Berechtigungen angezeigt.

  7. Klicken Sie auf Speichern.

gcloud

So weisen Sie mit der gcloud CLI IAM-Rollen für eine Ressource in einem Projekt zu:

  1. Rufen Sie die Projektnummer des Projekts ab, in dem die Ressource definiert ist.

    gcloud projects describe $(gcloud config get-value core/project) --format=value\(projectNumber\)

  2. Gewähren Sie Zugriff auf die Ressource.

    Führen Sie den folgenden Befehl aus, um mit der gcloud CLI externen Identitäten, die bestimmte Kriterien erfüllen, die Rolle „Storage Object Viewer“ (roles/storage.objectViewer) zuzuweisen.

    Nach Thema

    gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

    Nach Gruppe

    gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

    Nach Attribut

    gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

    Ersetzen Sie Folgendes:

    • BUCKET_ID: der Bucket, für den Zugriff gewährt werden soll
    • PROJECT_NUMBER: die Projektnummer des Projekts, das den Workload Identity-Pool enthält
    • POOL_ID: die Pool-ID des Workload Identity-Pools
    • SUBJECT: der erwartete Wert für das Attribut, das Sie google.subject zugeordnet haben
    • GROUP: der erwartete Wert für das Attribut, das Sie google.groups zugeordnet haben
    • ATTRIBUTE_NAME: der Name eines benutzerdefinierten Attributs in Ihrer Attributzuordnung
    • ATTRIBUTE_VALUE: Wert des benutzerdefinierten Attributs in Ihrer Attributzuordnung

    Sie können jeder Google Cloud-Ressource, die IAM-Zulassungsrichtlinien unterstützt, Rollen zuweisen.

Identitätsübertragung für ein Dienstkonto

  1. So erstellen Sie ein Dienstkonto für die externe Arbeitslast:

    1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.

      Enable the APIs

    2. Erstellen Sie ein Dienstkonto, das die Arbeitslast darstellt. Wir empfehlen, für jede Arbeitslast ein dediziertes Dienstkonto zu verwenden. Das Dienstkonto muss sich nicht im selben Projekt wie der Workload Identity-Pool befinden. Sie müssen sich aber auf das Projekt beziehen, das das Dienstkonto enthält.

    3. Gewähren Sie dem Dienstkonto Zugriff auf Ressourcen, auf die externe Identitäten zugreifen können sollen.

    4. Weisen Sie dem Dienstkonto die Nutzerrolle "Workload Identity" (roles/iam.workloadIdentityUser) zu.

  2. So gewähren Sie Zugriff auf eine föderierte Identität mithilfe der Identitätsübernahme des Dienstkontos über die Google Cloud Console oder die gcloud CLI:

Console

So weisen Sie der Google Cloud Console IAM-Rollen zu, um einer föderierten Identität mit einem Dienstkonto IAM-Rollen zuzuweisen:

Dienstkonto im selben Projekt

  1. So gewähren Sie einem Dienstkonto im selben Projekt Zugriff über die Identitätsübernahme des Dienstkontos:

    1. Rufen Sie die Seite Workload Identity-Pools auf.

      Zu Workload Identity-Pools

    2. Wählen Sie Zugriff gewähren aus.

    3. Wählen Sie im Dialogfeld Zugriff auf Dienstkonto gewähren die Option Zugriff mit Identitätsübernahme des Dienstkontos gewähren aus.

    4. Wählen Sie in der Liste Dienstkonten das Dienstkonto aus, das von den externen Identitäten übernommen werden soll. Gehen Sie dann so vor:

    5. Führen Sie eine der folgenden Aktionen aus, um auszuwählen, welche Identitäten im Pool die Identität des Dienstkontos übernehmen können:

      • Damit nur bestimmte Identitäten des Workload Identity-Pools die Identität des Dienstkontos übernehmen können, wählen Sie Nur Identitäten, die dem Filter entsprechen aus.

      • Wählen Sie in der Liste Attributname das Attribut aus, nach dem Sie filtern möchten.

      • Geben Sie im Feld Attributwert den erwarteten Wert des Attributs ein. Wenn Sie beispielsweise eine google.subject=assertion.sub-Attributzuordnung verwenden, legen Sie den Attributnamen auf subject und den Attributwert auf den Wert der sub-Anforderung in Tokens fest, die von Ihrem externen Identitätsanbieter ausgestellt werden.

    6. Klicken Sie zum Speichern der Konfiguration auf Speichern und dann auf Schließen.

Dienstkonto in einem anderen Projekt

  1. So gewähren Sie einem Dienstkonto in einem anderen Projekt Zugriff über die Identitätsübernahme des Dienstkontos:

    1. Rufen Sie die Seite Dienstkonten auf.

      Zur Seite „Dienstkonten“

    2. Wählen Sie das Dienstkonto aus, dessen Identität Sie übernehmen möchten.

    3. Klicken Sie auf Zugriff verwalten.

    4. Klicken Sie auf Hauptkonto hinzufügen.

    5. Geben Sie im Feld Neues Hauptkonto eine der folgenden Hauptkonto-IDs für die Identitäten in Ihrem Pool ein, die die Identität des Dienstkontos übernehmen.

      Nach Thema 

      principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT

      Ersetzen Sie Folgendes:

      • PROJECT_NUMBER: die Projektnummer
      • POOL_ID: die ID des Arbeitslastpools
      • SUBJECT: das einzelne Thema, das Ihrem IdP zugeordnet ist, z. B. administrator@example.com

      Nach Gruppe 

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP

      Ersetzen Sie Folgendes:

      • PROJECT_NUMBER: die Projektnummer
      • WORKLOAD_POOL_ID: die ID des Arbeitslastpools
      • GROUP: die Gruppe, die Ihrem IdP zugeordnet ist, z. B.: administrator-group@example.com

      Nach Attribut 

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE

      Ersetzen Sie Folgendes:

      • PROJECT_NUMBER: die Projektnummer
      • WORKLOAD_POOL_ID: die ID des Arbeitslastpools
      • ATTRIBUTE_NAME: eines der Attribute, die von Ihrem IdP zugeordnet wurden.
      • ATTRIBUTE_VALUE: der Wert des Attributs

      Nach Pool

      principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*

      Ersetzen Sie Folgendes:

      • PROJECT_NUMBER: die Projektnummer
      • WORKLOAD_POOL_ID: die ID des Arbeitslastpools

    6. Wählen Sie unter Rolle auswählen die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) aus.

    7. Klicken Sie auf Speichern, um die Konfiguration zu speichern.

gcloud

Führen Sie den folgenden Befehl aus, um mit der gcloud CLI externen Identitäten, die bestimmte Kriterien erfüllen, die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) zuzuweisen.

Nach Subjekt

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

Nach Gruppe

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

Nach Attribut

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

Ersetzen Sie Folgendes:

  • SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos.
  • PROJECT_NUMBER: die Projektnummer des Projekts, das den Workload Identity-Pool enthält
  • POOL_ID: die Pool-ID des Workload Identity-Pools
  • SUBJECT: der erwartete Wert für das Attribut, das Sie google.subject zugeordnet haben
  • GROUP: der erwartete Wert für das Attribut, das Sie google.groups zugeordnet haben
  • ATTRIBUTE_NAME: der Name eines benutzerdefinierten Attributs in Ihrer Attributzuordnung
  • ATTRIBUTE_VALUE: Wert des benutzerdefinierten Attributs in Ihrer Attributzuordnung

Anmeldedaten-Konfiguration herunterladen oder erstellen

Die Cloud-Clientbibliotheken und die gcloud CLI können automatisch externe Anmeldedaten abrufen und mit diesen die Identität eines Dienstkontos übernehmen. Damit Bibliotheken und Tools diesen Vorgang abschließen können, müssen Sie eine Konfigurationsdatei für Anmeldedaten angeben. Die Datei definiert Folgendes:

  • Wo externe Anmeldedaten abgerufen werden
  • Welcher Workload Identity-Pool und -Anbieter verwendet werden
  • Welches Dienstkonto übernommen wird

Für die X.509-Zertifikatsfederation ist außerdem eine Zertifikatskonfigurationsdatei erforderlich. Diese Datei enthält Pfade zu den X.509-Clientzertifikat- und privaten Schlüsseldateien.

So erstellen Sie Konfigurationsdateien für Anmeldedaten und Zertifikate:

Direkter Ressourcenzugriff

So erstellen Sie mit gcloud iam workload-identity-pools create-cred-config Konfigurationsdateien für Anmeldedaten und Zertifikate für den direkten Ressourcenzugriff:

Erstellen Sie Konfigurationsdateien für Anmeldedaten und Zertifikate, mit denen die Bibliothek ein Zugriffstoken mit einem X.509-Zertifikat abrufen kann.

gcloud iam workload-identity-pools create-cred-config
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --credential-cert-path CLIENT_CERT_PATH \
    --credential-cert-private-key-path CLIENT_KEY_PATH \
    --output-file=FILEPATH.json

Ersetzen Sie Folgendes:

  • PROJECT_NUMBER: Die Projektnummer des Projekts, das den Workload Identity-Pool enthält.
  • POOL_ID: Die ID des Workload Identity-Pools.
  • PROVIDER_ID: Die ID des Anbieters des Workload Identity-Pools.
  • CLIENT_CERT_PATH : Pfad der Zertifikatsdatei des Clients.
  • CLIENT_KEY_PATH : Pfad der privaten Schlüsseldatei des Clientzertifikats.
  • FILEPATH: die Datei, in der die Konfiguration gespeichert werden soll

Durch Ausführen dieses Befehls wird auch eine Zertifikatkonfigurationsdatei erstellt und am Standardspeicherort der Google Cloud CLI gespeichert:

  • Linux und macOS: ~/.config/gcloud/certificate_config.json

  • Windows: %APPDATA%\gcloud\certificate_config.json

Identitätsübertragung für ein Dienstkonto

So erstellen Sie mit gcloud iam workload-identity-pools create-cred-config Konfigurationsdateien für Anmeldedaten und Zertifikate mit Identitätsübernahme des Dienstkontos:

Erstellen Sie Konfigurationsdateien für Anmeldedaten und Zertifikate, mit denen die Bibliothek ein Zugriffstoken mit einem X.509-Zertifikat abrufen kann.

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --service-account-token-lifetime-seconds=SERVICE_ACCOUNT_TOKEN_LIFETIME \
    --credential-cert-path CLIENT_CERT_PATH \
    --credential-cert-private-key-path CLIENT_KEY_PATH \
    --output-file=FILEPATH.json

Ersetzen Sie Folgendes:

  • PROJECT_NUMBER: Die Projektnummer des Projekts, das den Workload Identity-Pool enthält.
  • POOL_ID: Die ID des Workload Identity-Pools.
  • PROVIDER_ID: Die ID des Anbieters des Workload Identity-Pools.
  • SERVICE_ACCOUNT_EMAIL: Wenn Sie die Identitätsübernahme des Dienstkontos verwenden, ersetzen Sie dies durch die E-Mail-Adresse des Dienstkontos.
  • SERVICE_ACCOUNT_TOKEN_LIFETIME: Wenn Sie die Identitätsübernahme des Dienstkontos verwenden, Lebensdauer des Zugriffstokens für das Dienstkonto in Sekunden, ist der Standardwert eine Stunde, wenn nicht angegeben. Lassen Sie dieses Flag weg, wenn Sie die Identitätsübernahme des Dienstkontos nicht verwenden. Wenn Sie eine Lebensdauer von mehr als einer Stunde angeben möchten, müssen Sie die constraints/iam.allowServiceAccountCredentialLifetimeExtension Einschränkung der Organisationsrichtlinie konfigurieren.
  • CLIENT_CERT_PATH : Pfad der Zertifikatsdatei des Clients.
  • CLIENT_KEY_PATH : Pfad der privaten Schlüsseldatei des Clientzertifikats.
  • FILEPATH: die Datei, in der die Konfiguration gespeichert werden soll

Durch Ausführen dieses Befehls wird auch eine Zertifikatkonfigurationsdatei erstellt und am Standardspeicherort der Google Cloud CLI gespeichert:

  • Linux und macOS: ~/.config/gcloud/certificate_config.json

  • Windows: %APPDATA%\gcloud\certificate_config.json

Anmeldedatenkonfiguration für den Zugriff auf Google Cloud verwenden

Gehen Sie so vor, damit Ihre Anmeldedatenkonfiguration von Tools und Clientbibliotheken verwendet werden kann:

  1. Initialisieren Sie eine Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS und verweisen Sie auf die Konfigurationsdatei für Anmeldedaten:

    Bash

      export GOOGLE_APPLICATION_CREDENTIALS=`pwd`/FILEPATH.json
    Dabei ist FILEPATH der relative Pfad zur Konfigurationsdatei für Anmeldedaten.

    PowerShell

      $env:GOOGLE_APPLICATION_CREDENTIALS = Resolve-Path 'FILEPATH.json'
    Dabei ist FILEPATH der relative Pfad zur Konfigurationsdatei für Anmeldedaten.

  2. Die Clientbibliothek muss die Zertifikatskonfigurationsdatei finden können. Die Zertifikatskonfigurationsdatei sollte entweder am Standardspeicherort der Google Cloud CLI gespeichert sein:

    • Linux und macOS: ~/.config/gcloud/certificate_config.json

    • Windows: %APPDATA%\gcloud\certificate_config.json

    oder auf die die Umgebungsvariable GOOGLE_API_CERTIFICATE_CONFIG verweist.

  3. Verwenden Sie eine Clientbibliothek oder ein Tool, das die Workload Identity-Föderation unterstützt und Anmeldedaten automatisch finden kann:

Go

Clientbibliotheken für Go unterstützen die X.509-Identitätsföderation von Arbeitslasten, wenn sie Version 0.8.0 oder höher des Moduls cloud.google.com/go/auth und Version 0.189.0 des Moduls google.golang.org/api verwenden.

Führen Sie den folgenden Befehl im Verzeichnis mit der go.mod-Datei für Ihr Modul aus, um zu prüfen, welche Version dieser Module Ihre Clientbibliothek verwendet:

  go list -m cloud.google.com/go/auth
  go list -m cloud.google.com/api

Python

Clientbibliotheken für Python unterstützen die X.509-Identitätsföderation von Arbeitslasten, wenn sie Version 2.32.0 oder höher des google-auth-Pakets verwenden.

Führen Sie den folgenden Befehl in der Umgebung aus, in der das Paket installiert ist, um zu ermitteln, welche Version dieses Pakets verwendet wird:

  pip show google-auth

Wenn Sie eine Projekt-ID für den Authentifizierungsclient angeben, können Sie die Umgebungsvariable GOOGLE_CLOUD_PROJECT festlegen oder Sie gestatten dem Client, automatisch nach der Projekt-ID zu suchen. Damit automatisch nach der Projekt-ID gesucht werden kann, muss das Dienstkonto in der Konfigurationsdatei in Ihrem Projekt die Rolle „Sucher“ (roles/browser) oder eine Rolle mit entsprechenden Berechtigungen haben. Weitere Informationen finden Sie im Nutzerhandbuch für das Paket google-auth.

gcloud

Verwenden Sie zum Authentifizieren mit der X.509-Workload Identity-Föderation den Befehl gcloud auth login:

  gcloud auth login --cred-file=FILEPATH.json

Ersetzen Sie FILEPATH durch den Pfad zur Konfigurationsdatei für Anmeldedaten.

Die Unterstützung für die X.509-Workload Identity-Föderation in der gcloud CLI ist in Version 488.0.0 und höher des gcloud CLI verfügbar.

Zugriffstoken mit einer einfachen Anfrage für den Zugriff auf Google Cloud abrufen

So rufen Sie das Zugriffstoken ab:

  1. Führe mit curl den Tokenaustausch mit mTLS und dem Clientzertifikat durch:

    curl --key CLIENT_CERT_KEY \
--cert CLIENT_CERT \
--request POST 'https://sts.mtls.googleapis.com/v1/token' \
--header "Content-Type: application/json" \
--data-raw '{
    "subject_token_type": "urn:ietf:params:oauth:token-type:mtls",
    "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
    "audience": "WORKLOAD_IDENTITY_POOL_URI",
    "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "scope": "https://www.googleapis.com/auth/cloud-platform",
}'

    Ersetzen Sie Folgendes:

    • CLIENT_CERT_KEY: Der private Schlüssel des Clientzertifikats
    • CLIENT_CERT: das Clientzertifikat

    • WORKLOAD_IDENTITY_POOL_URI: die URL des Workload Identity-Poolanbieters im folgenden Format:

      //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

  2. Verwenden Sie das im vorherigen Schritt generierte Bearer-Zugriffstoken, um auf Google Cloud-Ressourcen zuzugreifen, z. B.:

    curl -X GET 'https://storage.googleapis.com/my_object' -H "Authorization: Bearer $ACCESS_TOKEN"

Kontingente und Limits

In der folgenden Tabelle sind Kontingente und Limits aufgeführt.

Element Kontingente und Limits Hinweise
Anzahl der Trust-Anchor Limit: 3 Jedes Zertifikat darf maximal 32 KB groß sein.
Anzahl der Zwischenzertifikate Limit: 10 Jedes Zertifikat darf 32 KB nicht überschreiten.
Anzahl der Namenseinschränkungen, die bei der Validierung von Stamm- und Zwischenzertifikaten zulässig sind Limit: 10
Zwischenzertifikate, die dieselben Informationen zum Subjekt und zum öffentlichen Schlüssel des Subjekts haben Limit: 5 Dieses Limit gilt pro Trust-Anchor.
Tiefe der Zertifikatskette Limit: 5 Die maximale Tiefe für eine Zertifikatskette, einschließlich der Root- und Clientzertifikate.
Die Häufigkeit, mit der Zwischenzertifikate ausgewertet werden können, wenn versucht wird, die Vertrauenskette zu erstellen Limit: 100
Schlüssel der hochgeladenen und vom Kunden übergebenen Zertifikate

Limit: RSA-Schlüssel können von 2.048 bis 4.096 Bit sein

ECDSA-Zertifikate müssen entweder P-256- oder P-384-Kurven verwenden

 RSA-2048 und P-256 werden für normale Anwendungsfälle empfohlen. Verwenden Sie andere Algorithmen, um die Best Practices für die Sicherheit zu erfüllen.

Nächste Schritte