Ü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.

In der Vergangenheit 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. Sie benötigen die Rolle „Workload Identity-Pooladministrator“ (roles/iam.workloadIdentityPoolAdmin).

    Alternativ enthalten die einfachen Rollen „IAM-Inhaber“ (roles/owner) und „Bearbeiter“ (roles/editor) ebenfalls Berechtigungen zum Konfigurieren der Identitätsföderation. In einer Produktionsumgebung sollten Sie keine einfachen Rollen zuweisen, in einer Entwicklungs- oder Testumgebung ist dies aber unproblematisch.

  2. Erstellen Sie ein Google Cloud-Dienstkonto.

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

Workload Identity-Pool erstellen

Ein Workload Identity-Pool ist ein Container für eine Sammlung externer Identitäten. 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.

gcloud

Führen Sie den Befehl gcloud beta iam workload-identity-pools create aus, um einen Workload Identity-Pool zu erstellen:

gcloud beta iam workload-identity-pools create pool-id \
    --location="global" \
    --description="description" \
    --display-name="display-name"

Die Antwort sieht in etwa so aus:

Created WorkloadIdentityPool [pool-id].

REST

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

HTTP-Methode und URL:

POST https://iam.googleapis.com/v1beta/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 als Identitätsanbieter hinzufügen

Wenn Sie Azure als Identitätsanbieter für Ihren Workload Identity-Pool konfigurieren möchten, müssen Sie mindestens Folgendes angeben:

  • Eine ID für den Anbieter.

  • Die Workload Identity-Pool-ID aus dem vorherigen Abschnitt in diesem Dokument.

  • 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 in etwa 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. Beispiel:

    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' \
      -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' \
        -Headers @{Metadata="true"}
    

    Dadurch wird ein Zugriffstoken für die Azure-VM zurückgegeben, das Sie decodieren können, um die verfügbaren Anforderungen aufzurufen.

    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.

Sie können auch mehrere optionale Parameter 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 für Attributbedingungen finden Sie in der Übersicht zu Workload Identity-Föderation.

Das folgende Beispiel zeigt, wie Azure als Identitätsanbieter hinzugefügt wird:

gcloud

Führen Sie den Befehl gcloud beta iam workload-identity-pools providers create-oidc aus, um Azure als Identitätsanbieter hinzuzufügen:

gcloud beta 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 WorkloadIdentityPoolProvider [provider-id].

REST

Mit der Methode projects.locations.workloadIdentityPools.providers.create wird Azure als Anbieter hinzugefügt.

HTTP-Methode und URL:

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

JSON-Text anfordern:

{
  "issuerUrl": "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"
}

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.

Berechtigung zum Übernehmen der Identität eines Dienstkontos erteilen

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“ (roles/iam.workloadIdentityUser) zu.

So fügen Sie diese Rollenbindung für eine bestimmte verwaltete Identität hinzu:

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/managed-identity-object-id"

So fügen Sie diese Bindung für alle Identitäten in einem Pool hinzu:

gcloud iam service-accounts add-iam-policy-binding service-account-email \
    --role roles/iam.workloadIdentityUser \
    --member "principalSet://iam.googleapis.com/project/project-number/workloadIdentityPools/pool-id/groups/azure-tenant-id"

Sie können den Zugriff auch anhand von benutzerdefinierten Attributen gewähren. Beispiel:

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.custom-attribute-name/custom-attribute-value"

Wenn Sie den Zugriff widerrufen möchten, ersetzen Sie add-iam-policy-binding durch remove-iam-policy-binding.

Außerdem können Sie über die REST API oder Clientbibliotheken Bindungen hinzufügen oder widerrufen. Weitere Informationen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen.

Azure-Token gegen Google-Token austauschen

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

So tauschen Sie Anmeldedaten aus:

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

  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 kann das Token eines Drittanbieters gegen ein Google-Token ausgetauscht werden.

    Ersetzen Sie diese Werte in den folgenden Anweisungen:

    • project-number: Ihre Google Cloud-Projektnummer.
    • pool-id: Die ID des Workload Identity-Pools, den Sie zuvor in dieser Anleitung erstellt haben.
    • provider-id: Die ID des Identitätsanbieters, den Sie zuvor in dieser Anleitung konfiguriert haben.

    HTTP-Methode und URL:

    POST https://sts.googleapis.com/v1beta/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": "azure-id-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

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

    Ersetzen Sie diese Werte in den folgenden Anweisungen:

    • project-id: Ihre Google Cloud-Projekt-ID.
    • 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.

Weitere Informationen