Über Microsoft Azure auf Ressourcen zugreifen

In diesem Dokument erfahren Sie, wie Sie mit Identitätsföderation über Microsoft Azure auf Google Cloud-Ressourcen zugreifen.

Früher haben Anwendungen, die außerhalb von Google Cloud ausgeführt werden, Dienstkontoschlüssel für den Zugriff auf Google Cloud-Ressourcen verwendet. Mithilfe der Identitätsföderation können Sie zulassen, dass eine verwaltete Identität für eine Azure-Ressource die Identität eines Dienstkontos übernehmen kann. Dadurch kann Ihre Arbeitslast direkt mit einem kurzlebigen Zugriffstoken auf Google Cloud-Ressourcen zugreifen und der mit Dienstkontoschlüsseln verbundene Wartungs- und Sicherheitsaufwand entfällt.

Hinweis

  1. IAM, Resource Manager, Service Account Credentials, and Security Token Service (STS) APIs aktivieren.

    Aktivieren Sie die APIs

  2. Sie benötigen die Rollen "Workload Identity-Pooladministrator" (roles/iam.workloadIdentityPoolAdmin) und "Dienstkontoadministrator" (roles/iam.serviceAccountAdmin) für das Projekt.

    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.

  3. Aktualisieren Sie die Organisationsrichtlinie für Ihre Organisation, um Föderationen von Azure zuzulassen.

  4. Erstellen Sie ein Google Cloud-Dienstkonto.

  5. Gewähren Sie dem Dienstkonto Zugriff, um die für Ihre Arbeitslast erforderlichen Google Cloud APIs aufzurufen.

Identitätsanbieter-Einstellungen für Azure

Wenn Sie Azure als Identitätsanbieter für den Workload Identity-Pool hinzufügen, müssen Sie Folgendes angeben:

  • Eine ID für den Anbieter.

  • Ihre Azure-Mandanten-ID.

  • Eine Liste mit Attributzuordnungen, die die Anforderungen eines Tokens für eine von Azure verwaltete Identität den Attributen in einem Google-Token zuordnen. Verwenden Sie assertion, um auf das Azure-Token zu verweisen, google für Google-Attribute und attribute für benutzerdefinierte Attribute.

    Es gibt zwei Google-Attribute: google.subject und google.groups. Sie können auf diese Attribute in IAM-Rollenbindungen verweisen. google.subject wird auch in Cloud Logging-Logeinträgen angezeigt.

    Sie müssen eine Zuordnung für google.subject bereitstellen. Im Allgemeinen empfehlen wir die Zuordnung zu assertion.sub, das die Objekt-ID einer verwalteten Identität enthält, die Sie im nächsten Abschnitt erstellen. Damit erhalten Sie eine stabile Kennung zur Verwendung in IAM-Rollenbindungen. Die Zuordnung sieht so aus:

    google.subject=assertion.sub
    

    Für komplexere Assertions können Sie die Common Expression Language verwenden. Wenn Ihr Workload Identity-Pool beispielsweise mehrere Identitätsanbieter enthält, können Sie ein Präfix anhängen, um zwischen diesen zu unterscheiden:

    google.subject="azure::" + assertion.tid + "::" + assertion.sub
    

    Das Feld google.subject darf höchstens 127 Zeichen enthalten.

    Sie können auch benutzerdefinierte Attribute angeben. Im Folgenden wird zum Beispiel assertion.tid zu attribute.tid zugeordnet:

    attribute.tid=assertion.tid
    

    Im folgenden Beispiel wird ein Anzeigename anhand des Werts von assertion.oid zugewiesen:

    attribute.managed_identity_name={
    "8bb39bdb-1cc5-4447-b7db-a19e920eb111":"workload1",
    "55d36609-9bcf-48e0-a366-a3cf19027d2a":"workload2"
    }[assertion.oid]
    

    Wenn Sie eine vollständige Liste der Anforderungen abrufen möchten, auf die Sie verweisen können, rufen Sie ein Zugriffstoken für eine Azure-VM in Ihrer Arbeitslast ab. Ersetzen Sie in der Anfrage den Parameter resource durch den vollständigen Ressourcennamen des Workload Identity-Pools.

    Beispiele:

    curl

    curl -s \
      'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID&object_id=MANAGED_IDENTITY_OBJECT_ID' \
      -H Metadata:true -H "Cache-Control: no-cache"
    

    PowerShell

    Invoke-WebRequest \
        -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID&object_id=MANAGED_IDENTITY_OBJECT_ID' \
        -Headers @{Metadata="true"}
    

    Die Antwort ist ein JSON-Objekt mit einem Feld access_token, das ein Zugriffstoken für die Azure-VM enthält. So decodieren Sie das Zugriffstoken und zeigen die verfügbaren Anforderungen an:

    1. Kopieren Sie das gesamte Zugriffstoken.
    2. Rufen Sie in einem Webbrowser https://jwt.ms/ auf.
    3. Fügen Sie das Zugriffstoken in das Textfeld ein.
    4. Klicke auf Anforderungen.

    Wenn Sie auf einen bestimmten Teil eine Anforderung in einem Ausdruck verweisen möchten, verwenden Sie die CEL-Funktion extract(), die einen Wert aus einer Anforderung anhand einer von Ihnen bereitgestellten Vorlage extrahiert. Weitere Informationen zu extract() finden Sie unter Werte aus Attributen extrahieren.

    Verwenden Sie die Funktion has(), um zu prüfen, ob Anmeldedaten eine Anforderung enthalten.

Optional können Sie auch Folgendes angeben:

  • Einen Anzeigenamen und eine Beschreibung.

  • Eine Attributbedingung zur Festlegung der Attribute, die das Hauptkonto enthalten muss. Die Bedingung kann für Anforderungen in den Azure-Anmeldedaten oder für Attribute in den Google-Anmeldedaten gelten. Alle Anfragen, die die Bedingung nicht erfüllen, werden abgelehnt.

    Attributbedingungen werden als CEL-Ausdruck formatiert, der einen booleschen Wert zurückgibt. Der folgende Ausdruck lehnt beispielsweise Anfragen von Identitäten ab, die nicht Mitglied einer bestimmten Gruppe sind:

    "e968c2ef-047c-498d-8d79-16ca1b61e77e" in assertion.groups
    

    Weitere Informationen zu gängigen Anwendungsfällen finden Sie unter Attributbedingungen.

Workload Identity-Pool und -Poolanbieter erstellen

Mit einem Workload Identity-Pool können Sie externe Identitäten organisieren und verwalten. Workload Identity-Pools sind voneinander isoliert, ein einzelner Pool kann jedoch eine beliebige Anzahl von Dienstkonten imitieren. Im Allgemeinen empfehlen wir, für jede Umgebung einen neuen Pool zu erstellen, z. B. für Entwicklung, Staging oder Produktion.

Sie müssen eine ID angeben, um einen neuen Workload Identity-Pool zu erstellen. Sie können auch eine optionale Beschreibung und einen Anzeigenamen angeben. Die ID darf nicht mit gcp- beginnen. Dieses Präfix ist für die Verwendung durch Google reserviert.

Nachdem Sie den Workload Identity-Pool erstellt haben, können Sie einen Workload Identity-Pool-Anbieter hinzufügen. Jeder Workload Identity-Pool-Anbieter stellt einen bestimmten Identitätsanbieter dar, wie beispielsweise Azure. Ein einzelner Pool kann mehrere Anbieter enthalten. Zum Erstellen des Anbieter benötigen Sie die unter Identitätsanbieter-Einstellungen für Azure auf dieser Seite beschriebenen Informationen.

Console

  1. Rufen Sie in der Cloud Console die Seite Neuer Arbeitslastanbieter und -anbieterpool auf.

    Zum neuen Arbeitslastanbieter und -anbieterpool

  2. Geben Sie einen Namen für den Workload Identity-Pool ein.

    Die Cloud Console verwendet den Namen zum Erstellen einer Pool-ID: Klicken Sie zum Ändern der Pool-ID auf Bearbeiten. Sie können die Pool-ID später nicht mehr ändern.

  3. Optional: Geben Sie eine Beschreibung des Workload Identity-Pools ein.

  4. Klicken Sie auf Weiter.

  5. Wählen Sie in der Drop-down-Liste Anbieter auswählen die Option OpenID Connect (OIDC) aus und klicken Sie dann auf Weiter.

  6. Geben Sie einen Namen für den Anbieter ein.

    Die Cloud Console verwendet den Namen zum Erstellen einer Anbieter-ID: Klicken Sie zum Ändern der Anbieter-ID auf Bearbeiten. Sie können die Anbieter-ID später nicht mehr ändern.

  7. Geben Sie die Aussteller-URL ein und klicken Sie auf Weiter.

    Bei Azure verwendet die Aussteller-URL das Format https://sts.windows.net/AZURE_TENANT_ID.

  8. Klicken Sie zum Konfigurieren der Attributzuordnung auf Zuordnung bearbeiten.

    Mithilfe der Attributzuordnung können Sie Informationen zu externen Identitäten verwenden, um einer Teilmenge dieser Identitäten Zugriff zu gewähren. Für Azure empfehlen wir die Zuordnung von google.subject zu assertion.sub. Andere Zuordnungen sind optional.

    Weitere Informationen finden Sie unter Identitätsanbieter-Einstellungen für Azure auf dieser Seite.

  9. Optional: Wenn Sie eine Attributbedingung angeben möchten, mit der die authentifizierenden Identitäten angegeben werden, klicken Sie auf Bedingung hinzufügen und geben Sie einen gültigen CEL-Ausdruck (Common Expression Language) ein. Weitere Informationen finden Sie unter Attributbedingungen.

  10. Klicken Sie auf Speichern, um den Workload Identity-Pool und -Poolanbieter zu erstellen.

gcloud

Um einen Workload Identity-Pool zu erstellen, verwenden Sie den Befehl gcloud iam workload-identity-pools create:

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

Die Antwort sieht in etwa so aus:

Created workload identity pool [POOL_ID].

Um einen Workload Identity-Poolanbieter hinzufügen können Sie den Befehl gcloud iam workload-identity-pools providers create-oidc verwenden:

gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://sts.windows.net/AZURE_TENANT_ID" \
    --location="global" \
    --attribute-mapping="google.subject=assertion.sub"

Die Antwort sieht in etwa so aus:

Created workload identity pool provider [PROVIDER_ID].

REST

So erstellen Sie einen Workload Identity-Pool:

Die Methode projects.locations.workloadIdentityPools.providers.create fügt Azure als Anbieter hinzu.

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1/projects/project-id/locations/global/workloadIdentityPools/pool-id/providers?workloadIdentityPoolProviderId=provider-id

JSON-Text anfordern:

{
  "attributeMapping": {
    "google.subject": "assertion.sub"
  },
  "oidc": {
    "issuerUri": "https://sts.windows.net/azure-tenant-id"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Die Methode gibt eine Operation mit langer Ausführungszeit zurück, die in etwa so aussieht:

{
  "name": "projects/project-number/locations/global/workloadIdentityPools/pool-id/providers/provider-id/operations/operation-id"
}

So fügen Sie einen Workload Identity-Poolanbieter hinzu:

Mit der Methode projects.locations.workloadIdentityPools.create wird ein Workload Identity-Pool erstellt.

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1/projects/project-id/locations/global/workloadIdentityPools?workloadIdentityPoolId=pool-id

JSON-Text anfordern:

{
  "description": "description",
  "display-name": "display-name"
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Die Methode gibt eine Operation mit langer Ausführungszeit zurück, die in etwa so aussieht:

{
  "name": "projects/project-number/locations/global/workloadIdentityPools/pool-id/operations/operation-id"
}

Azure-Mandanten für die Identitätsföderation konfigurieren

So bereiten Sie Ihren Azure-Mandanten für die Identitätsföderation vor:

  1. Erstellen Sie eine Azure AD-Anwendung und ein Hauptkonto und legen Sie als Anwendungs-ID-URI den vollständigen Ressourcennamen des Anbieters fest, den Sie im vorherigen Abschnitt erstellt haben:

    https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
    
  2. Erstellen Sie eine verwaltete Identität und notieren Sie die zugehörige Objekt-ID.

  3. Weisen Sie die verwaltete Identität der virtuellen Maschine zu, der Sie Zugriff auf Google Cloud-Ressourcen gewähren möchten.

Externe Identitäten erlauben, die Identität eines Dienstkontos zu übernehmen

Externe Identitäten können auf die meisten Google Cloud-Ressourcen nicht direkt zugreifen. Stattdessen legen Sie für diese Identitäten die Übernahme der Identität eines Dienstkontos fest und weisen dazu die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) für das Dienstkonto zu. Wenn die externen Identitäten ein Dienstkonto imitieren, haben sie dieselben Rollen und Berechtigungen wie das Dienstkonto.

So weisen Sie Azure-Identitäten die Rolle „Workload Identity-Nutzer“ zu:

Console

Bevor Sie die Rolle „Workload Identity-Nutzer“ zuweisen, entscheiden Sie, welche Identitäten Sie als Identitätsanbieter für das Dienstkonto zulassen wollen. Sie können die Rolle allen Identitäten im Workload Identity-Pool oder nur einem Teil dieser Identitäten gemäß der Attributzuordnung zuweisen:

Identitäten Attributname Attributwert
Eine bestimmte verwaltete Identität subject MANAGED_IDENTITY_OBJECT_ID
Alle Azure-Identitäten im jeweiligen Azure-Mandanten group AZURE_TENANT_ID
Alle Identitäten mit einem bestimmten Attributwert ATTRIBUTE_NAME ATTRIBUTE_VALUE

Gewähren Sie dann Zugriff auf das Dienstkonto und laden Sie optional eine Konfigurationsdatei für das automatische Generieren von Anmeldedaten herunter:

  1. Rufen Sie in der Cloud Console die Seite Workload Identity-Pools auf.

    Zu Workload Identity-Pools

  2. Suchen Sie den Workload Identity-Pool, der die Azure-Identitäten enthält, und klicken Sie dann auf das Symbol Bearbeiten. Die Cloud Console zeigt Details zum Workload Identity-Pool an.

  3. Klicken Sie auf Zugriff erlauben.

  4. Wählen Sie in der Drop-down-Liste Dienstkonto das Dienstkonto aus, das die externen Identitäten imitieren soll.

  5. Wählen Sie aus, welche Identitäten im Pool die Identität des Dienstkontos übernehmen können.

    Wählen Sie Alle Identitäten im Pool, damit alle Identitäten die Identität des Dienstkontos übernehmen können.

    Damit nur eine Teilmenge von Identitäten die Identität des Dienstkontos übernehmen kann, wählen Sie Nur Identitäten, die dem Filter entsprechen aus und gehen dann so vor:

    1. Wählen Sie in der Drop-down-Liste Attributname das auszuwertende Attribut aus.

      Nur zugeordnete Attribute werden in der Liste angezeigt. Die Präfixe google. und attribute. werden nicht angezeigt.

    2. Geben Sie im Feld Attributwert den erwarteten Wert des Attributs ein.

  6. Klicken Sie auf Speichern.

    Wenn die Identitäten bereits Zugriff auf das Dienstkonto hatten, werden in der Cloud Console Details zum Workload Identity-Pool angezeigt. Sie können die restlichen Schritte überspringen.

    Falls die Identitäten Zugriff auf das Dienstkonto haben, zeigt die Cloud Console das Dialogfeld Anwendung konfigurieren an.

  7. Optional: So laden Sie eine Konfigurationsdatei zum automatischen Generieren von Anmeldedaten herunter:

    1. Wählen Sie in der Drop-down-Liste Anbieter den Anbieter aus, der die Azure-Identitäten enthält, die die Identität des Dienstkontos übernehmen.

    2. Klicken Sie auf den Konfiguration herunterladen, um eine JSON-Konfigurationsdatei herunterzuladen.

  8. Klicken Sie auf Ablehnen.

gcloud

Bevor Sie die Rolle „Workload Identity-Nutzer“ zuweisen, entscheiden Sie, welche Identitäten Sie als Identitätsanbieter für das Dienstkonto zulassen wollen. Sie können die Rolle allen Identitäten im Workload Identity-Pool oder nur einem Teil dieser Identitäten gemäß der Attributzuordnung zuweisen:

Identitäten ID-Format
Eine bestimmte verwaltete Identität principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MANAGED_IDENTITY_OBJECT_ID
Alle Azure-Identitäten im jeweiligen Azure-Mandanten principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/AZURE_TENANT_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/*

Führen Sie dann den Befehl gcloud iam service-accounts add-iam-policy-bindingaus:

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="PRINCIPAL"

Ersetzen Sie die folgenden Werte:

  • SERVICE_ACCOUNT_EMAIL: Die E-Mail-Adresse des Dienstkontos.
  • PRINCIPAL: Die externen Identitäten, die die Identität des Dienstkontos übernehmen werden.

REST

Bevor Sie die Rolle „Workload Identity-Nutzer“ zuweisen, entscheiden Sie, welche Identitäten Sie als Identitätsanbieter für das Dienstkonto zulassen wollen. Sie können die Rolle allen Identitäten im Workload Identity-Pool oder nur einem Teil dieser Identitäten gemäß der Attributzuordnung zuweisen:

Identitäten ID-Format
Eine bestimmte verwaltete Identität principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MANAGED_IDENTITY_OBJECT_ID
Alle Azure-Identitäten im jeweiligen Azure-Mandanten principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/AZURE_TENANT_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/*

Verwenden Sie dann das Muster „Read-Modify-Write“, um die Richtlinie zu aktualisieren:

  1. IAM-Richtlinie des Dienstkontos lesen
  2. Ändern Sie die Richtlinie, um die Rolle zuzuweisen.
  3. Schreiben Sie die aktualisierte Richtlinie.

IAM-Richtlinie des Dienstkontos lesen

Die Methode serviceAccounts.getIamPolicy ruft die IAM-Richtlinie eines Dienstkontos ab.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • SA_ID: Die ID Ihres Dienstkontos. Dies kann entweder die E-Mail-Adresse des Dienstkontos im Format SA_NAME@PROJECT_ID.iam.gserviceaccount.com oder die eindeutige numerische ID des Dienstkontos sein.

  • POLICY_VERSION: Die Richtlinienversion, die zurückgegeben werden soll. Anfragen sollten die neueste Richtlinienversion angeben. Diese ist Richtlinienversion 3. Weitere Informationen finden Sie unter Richtlinienversion beim Abrufen einer Richtlinie festlegen.

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:getIamPolicy

JSON-Text anfordern:

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie müssten in etwa folgende JSON-Antwort erhalten:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Wenn keine Richtlinie vorhanden ist, enthält die Antwort nur das Standard-etag. Wenn Sie diese Antwort erhalten, fügen Sie ein version-Feld hinzu, das auf 3 gesetzt ist, und ein bindings-Feld, das auf ein leeres Array gesetzt ist.

Ändern Sie die Richtlinie, um Ihren Hauptkonten die entsprechenden Rollen zuzuweisen.

Um eine Rolle zuzuweisen, ändern Sie das Array bindings im Antworttext:

  • Wenn keine Bindung für die Rolle vorhanden ist, fügen Sie dem Array bindings ein neues Objekt hinzu, das die Rolle und das Hauptkonto definiert, dem Sie die Rolle zuweisen möchten.
  • Wenn für die Rolle bereits eine Bindung vorhanden ist, fügen Sie das neue Hauptkonto der Liste der vorhandenen Hauptkonten hinzu.

Beispiel:

Wenn Sie allen Identitäten im Pool die Rolle „Workload Identity-Nutzer“ (roles/iam.workloadIdentityUser) zuweisen möchten, ändern Sie das im vorherigen Schritt gezeigte Beispiel so:

{
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.workloadIdentityUser",
      "members": [
        "principalSet://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/my-pool/*"
      ]
    },
    {
      "role": "roles/iam.serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Schreiben Sie die aktualisierte Richtlinie.

Die Methode serviceAccounts.setIamPolicy legt eine aktualisierte IAM-Richtlinie für das Dienstkonto fest.

Ersetzen Sie diese Werte in den folgenden Anfragedaten:

  • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
  • SA_ID: Die ID Ihres Dienstkontos. Dies kann entweder die E-Mail-Adresse des Dienstkontos im Format SA_NAME@PROJECT_ID.iam.gserviceaccount.com oder die eindeutige numerische ID des Dienstkontos sein.

  • POLICY: Eine JSON-Darstellung der Richtlinie, die Sie festlegen möchten. Weitere Informationen zum Format einer Richtlinie finden Sie in der Richtlinienreferenz.

    Zum Festlegen der im vorherigen Schritt angezeigten Richtlinie ersetzen Sie beispielsweise policy durch Folgendes:

    {
      "version": 1,
      "etag": "BwUqLaVeua8=",
      "bindings": [
        {
          "role": "roles/iam.workloadIdentityUser",
          "members": [
            "principalSet://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/my-pool/*"
          ]
        },
        {
          "role": "roles/iam.serviceAccountAdmin",
          "members": [
            "user:admin@example.com"
          ]
        }
      ]
    }
    

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:setIamPolicy

JSON-Text anfordern:

{
  "policy": POLICY
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Die Antwort enthält die aktualisierte Richtlinie.

Google-Anmeldedaten generieren

Wenn Sie eine unterstützte Clientbibliothek verwenden, können Sie die Clientbibliothek so konfigurieren, dass Google-Anmeldedaten automatisch generiert werden. Alternativ können Sie Azure-Anmeldedaten manuell generieren und diese dann gegen Google-Anmeldedaten austauschen.

Wir empfehlen Ihnen, nach Möglichkeit Anmeldedaten automatisch zu generieren, damit Sie den Token-Exchange-Prozess nicht selbst implementieren müssen.

Anmeldedaten automatisch generieren

Wenn Sie mit einer Clientbibliothek für eine der folgenden Sprachen auf Google Cloud zugreifen, können Sie die Clientbibliothek so konfigurieren, dass Anmeldedaten automatisch mithilfe der Identitätsföderation erzeugt werden:

C++

Die meisten Google Cloud-Clientbibliotheken für C++ unterstützen die Identitätsföderation mithilfe eines ChannelCredentials-Objekts, das durch Aufrufen von grpc::GoogleDefaultCredentials() erstellt wird. Zur Initialisierung dieser Anmeldedaten müssen Sie die Clientbibliotheken ab Version 1.36.0 von gRPC erstellen.

Da die Cloud Storage-Clientbibliothek für C++ die REST API und nicht gRPC verwendet, wird die Identitätsföderation nicht unterstützt.

Go

Clientbibliotheken für Go unterstützen die Identitätsföderation, wenn sie Version 0.0.0-2021218202405-ba52d332ba99 oder höher des Moduls golang.org/x/oauth2 verwenden.

Führen Sie die folgenden Befehle aus, um zu überprüfen, welche Version dieses Moduls in Ihrer Clientbibliothek verwendet wird:

cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2

Java

Clientbibliotheken für Java unterstützen die Identitätsföderation, wenn sie Version 0.24.0 oder höher des com.google.auth:google-auth-library-oauth2-http-Artefakts verwenden.

Führen Sie den folgenden Maven-Befehl in Ihrem Anwendungsverzeichnis aus, um zu überprüfen, welche Version dieses Artefakts Ihre Clientbibliothek verwendet:

mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http

Node.js

Clientbibliotheken für Node.js unterstützen die Identitätsföderation, wenn sie Version 7.0.2 oder höher des google-auth-library-Pakets verwenden.

Führen Sie den folgenden Befehl in Ihrem Anwendungsverzeichnis aus, um zu überprüfen, welche Version dieses Pakets verwendet wird:

npm list google-auth-library

Wenn Sie ein GoogleAuth-Objekt erstellen, können Sie eine Projekt-ID angeben oder GoogleAuth erlauben, 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 unter README für das Paket google-auth-library.

Python

Clientbibliotheken für Python unterstützen die Identitätsföderation, wenn sie Version 1.7.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.

Um die Clientbibliothek so zu konfigurieren, dass Anmeldedaten automatisch generiert werden, erstellen Sie eine JSON-Konfigurationsdatei. Sie können diese Datei mit der Cloud Console oder dem gcloud-Tool erstellen.

Console

Folgen Sie zuerst der Anleitung auf dieser Seite, damit externe Identitäten die Identität eines Dienstkontos übernehmen können. Sie können dann eine JSON-Konfigurationsdatei für jedes Dienstkonto erstellen, dessen Identität die externen Identitäten übernehmen können.

So erstellen Sie eine JSON-Konfigurationsdatei:

  1. Rufen Sie in der Cloud Console die Seite Workload Identity-Pools auf.

    Zu Workload Identity-Pools

  2. Suchen Sie den Workload Identity-Pool, der den zu verwendenden Identitätsanbieter enthält, und klicken Sie auf das Symbol Bearbeiten. Die Cloud Console zeigt Details zum Workload Identity-Pool an.
  3. Klicken Sie auf Verbundene Dienstkonten.
  4. Suchen Sie das Dienstkonto, das Sie verwenden möchten, und klicken Sie auf Herunterladen.
  5. Wählen Sie in der Drop-down-Liste Anbieter den Anbieter aus, der die Azure-Identitäten enthält, die die Identität des Dienstkontos übernehmen.
  6. Klicken Sie auf Konfiguration herunterladen, um die JSON-Konfigurationsdatei herunterzuladen, und klicken Sie dann auf Fertig.

gcloud

Führen Sie zum Erstellen einer JSON-Konfigurationsdatei den Befehl gcloud iam workload-identity-pools create-cred-config aus:

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --output-file=FILEPATH \
    --azure

Ersetzen Sie die folgenden Werte:

  • PROJECT_NUMBER: Die numerische ID für das Projekt.
  • POOL_ID: Die ID des Workload-Identitätspools.
  • PROVIDER_ID: Die ID für den Identitätsanbieter des Workloads.
  • SERVICE_ACCOUNT_EMAIL: Die E-Mail-Adresse des Dienstkontos, dessen Identität angenommen werden soll.
  • FILEPATH: Der Dateipfad für die Konfigurationsdatei.

Nachdem Sie die Konfigurationsdatei generiert haben, legen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS auf den Dateipfad für die Konfigurationsdatei fest. Diese Umgebungsvariable weist die Clientbibliothek an, für die Authentifizierung die Standardanmeldedaten für Anwendungen zu verwenden. Weitere Informationen finden Sie unter Anmeldedaten automatisch finden.

Anmeldedaten manuell austauschen

Wenn Ihre verwaltete Azure-Identität in der Lage ist, die Identität eines Dienstkontos zu übernehmen, können Sie deren Anmeldedaten manuell gegen Google-Anmeldedaten austauschen.

So tauschen Sie Anmeldedaten aus:

  1. Verwenden Sie den Azure Instance Metadata Service (IMDS), um ein Azure-Zugriffstoken abzurufen.

    Legen Sie für den Abfrageparameter resource den folgenden Wert fest:

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

    Legen Sie den Abfrageparameter object_id auf die Objekt-ID der verwalteten Identität fest, die Sie zuvor erstellt haben.

  2. Übergeben Sie das Azure-Zugriffstoken an die Methode token() des Security Token Service, um ein föderiertes Zugriffstoken abzurufen:

    REST

    Mit der Methode token wird das Token eines Drittanbieters gegen ein Google-Token ausgetauscht.

    Ersetzen Sie diese Werte in den folgenden Anfragedaten:

    • PROJECT_NUMBER: Ihre Google Cloud-Projektnummer.
    • POOL_ID: Die ID des von Ihnen erstellten Workload Identity-Pools.
    • PROVIDER_ID: Die ID des von Ihnen konfigurierten Identitätsanbieters.
    • ACCESS_TOKEN: Das Token des Identitätsanbieters.

    HTTP-Methode und URL:

    POST https://sts.googleapis.com/v1/token

    JSON-Text anfordern:

    {
      "audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID",
      "grantType": "urn:ietf:params:oauth:grant-type:token-exchange",
      "requestedTokenType": "urn:ietf:params:oauth:token-type:access_token",
      "scope": "https://www.googleapis.com/auth/cloud-platform",
      "subjectTokenType": "urn:ietf:params:oauth:token-type:jwt",
      "subjectToken": "ACCESS_TOKEN"
    }
    

    Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

     

    Die Methode gibt ein föderiertes Token zurück.

  3. Rufen Sie generateAccessToken() auf, um das föderierte Token gegen ein Dienstkonto-Zugriffstoken auszutauschen. Eine begrenzte Anzahl an Google Cloud APIs unterstützt föderierte Tokens. Alle Google Cloud APIs unterstützen Dienstkonto-Zugriffstokens.

    REST

    Die Methode serviceAccounts.generateAccessToken der Service Credentials API generiert ein OAuth 2.0-Zugriffstoken für ein Dienstkonto.

    Ersetzen Sie diese Werte in den folgenden Anfragedaten:

    • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
    • SA_ID: Die ID Ihres Dienstkontos. Dies kann entweder die E-Mail-Adresse des Dienstkontos im Format SA_NAME@PROJECT_ID.iam.gserviceaccount.com oder die eindeutige numerische ID des Dienstkontos sein.
    • token: Das föderierte Zugriffstoken.

    HTTP-Methode und URL:

    POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken

    JSON-Text anfordern:

    {
      "scope": [
        "https://www.googleapis.com/auth/cloud-platform"
      ]
    }
    

    Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

    Wenn die Anfrage generateAccessToken erfolgreich war, enthält der Antworttext ein OAuth 2.0-Zugriffstoken und eine Ablaufzeit. Das accessToken kann dann verwendet werden, um eine Anfrage im Namen des Dienstkontos zu authentifizieren, bis die expireTime erreicht wurde:

    {
      "accessToken": "eyJ0eXAi...NiJ9",
      "expireTime": "2020-04-07T15:01:23.045123456Z"
    }
    

Sobald Sie ein Zugriffstoken für ein Dienstkonto haben, können Sie damit Google Cloud APIs aufrufen. Dazu nehmen Sie das Token in den Header Authorization Ihrer Anfrage auf:

Authorization: Bearer SERVICE_ACCOUNT_ACCESS_TOKEN

Die Anfrage ist als Dienstkonto autorisiert.

Nächste Schritte