Dienstkonten an Ressourcen anhängen

Bei einigen Google Cloud-Ressourcen können Sie ein nutzerverwaltetes Dienstkonto angeben, das von der Ressource als Standardidentität verwendet wird. Dieser Vorgang wird als Anhängen des Dienstkontos an die Ressource oder Verknüpfen des Dienstkontos mit der Ressource bezeichnet.

Wenn die Ressource auf andere Google Cloud-Dienste und -Ressourcen zugreifen muss, verwendet sie das angehängte Dienstkonto als Identität. Wenn Sie beispielsweise ein Dienstkonto an eine Compute Engine-Instanz anhängen, und die Anwendungen auf der Instanz eine Clientbibliothek verwenden, um Google Cloud APIs aufzurufen, authentifizieren sich diese Anwendungen automatisch als das angehängte Dienstkonto.

Auf dieser Seite wird beschrieben, wie Sie Dienstkonten konfigurieren, damit Sie sie an Ressourcen anhängen können.

Hinweis

Dienstkonto an eine Ressource anhängen

In den meisten Fällen müssen Sie beim Erstellen einer Ressource ein Dienstkonto an eine Ressource anhängen. Nachdem die Ressource erstellt wurde, können Sie nicht mehr ändern, welches Dienstkonto an der Ressource angehängt ist. Compute Engine-Instanzen sind eine Ausnahme von dieser Regel. Sie können je nach Bedarf ändern, welches Dienstkonto an eine Instanz angehängt ist.

Bevor Sie ein Dienstkonto an eine Ressource anhängen, müssen Sie das Dienstkonto konfigurieren. Dieser Vorgang unterscheidet sich je nachdem, ob sich das Dienstkonto und die Ressource im selben Projekt oder in verschiedenen Projekten befinden. Nachdem Sie das Dienstkonto konfiguriert haben, können Sie die Ressource erstellen und das Dienstkonto an diese Ressource anhängen.

Für eine Ressource im selben Projekt konfigurieren

Bevor Sie ein Dienstkonto an eine andere Ressource im selben Projekt anhängen, weisen Sie dem Dienstkonto Rollen zu, damit es auf die entsprechenden Ressourcen zugreifen kann, genauso wie Sie anderen Hauptkonten Rollen zuweisen würden.

Für eine Ressource in einem anderen Projekt konfigurieren

In manchen Fällen müssen Sie ein Dienstkonto an eine Ressource anhängen, die sich in einem anderen Projekt befindet. Wenn Sie beispielsweise alle Dienstkonten in einem einzelnen Projekt erstellen, müssen Sie sie möglicherweise mit einer neuen Ressource in einem anderen Projekt verknüpfen.

Führen Sie die folgenden Schritte aus, bevor Sie ein Dienstkonto an eine Ressource in einem anderen Projekt anhängen:

  1. Führen Sie im Projekt, in dem sich das Dienstkonto befindet, die Schritte auf dieser Seite aus, um zu ermöglichen, dass Dienstkonten projektübergreifend angehängt werden können.
  2. Identifizieren Sie das Projekt, in dem Sie die Ressource erstellen möchten.

  3. Ermitteln Sie den Art der Ressource, an die Sie das Dienstkonto anhängen möchten, sowie den Dienst, der diese Art von Ressource besitzt.

    Wenn Sie beispielsweise ein Pub/Sub-Abo erstellen, ist Pub/Sub der Dienst, der die Ressource besitzt.

  4. Suchen Sie die E-Mail-Adresse des Dienst-Agents für den Dienst.

    Unterschiedliche Dienste verwenden unterschiedliche Dienst-Agents. Weitere Informationen finden Sie unter Dienst-Agents.

  5. Gewähren Sie den Dienst-Agents die Rolle "Ersteller von Dienstkonto-Tokens" (roles/iam.serviceAccountTokenCreator):

    Console

    1. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf:

      Zur Seite „Dienstkonten“

    2. Wählen Sie das Projekt aus, dem das Dienstkonto gehört, das Sie an eine Ressource anhängen möchten.

    3. Klicken Sie auf die E-Mail-Adresse des Dienstkontos, das Sie an eine Ressource anhängen möchten.

    4. Wechseln Sie zum Tab Berechtigungen und suchen Sie den Abschnitt Hauptkonten mit Zugriff auf dieses Dienstkonto.

    5. Klicken Sie auf Zugriff gewähren und geben Sie dann die E-Mail-Adresse des Dienst-Agents ein.

    6. Klicken Sie auf Rolle auswählen, geben Sie Service Account Token Creator ein und klicken Sie dann auf die Rolle.

    7. Klicken Sie auf Speichern, um die Änderungen zu speichern.

    8. Optional: Wenn Sie die Rolle einem anderen Dienst-Agent zuweisen möchten, wiederholen Sie die vorherigen Schritte.

    gcloud

    Führen Sie den Befehl gcloud iam service-accounts add-iam-policy-binding aus:

    gcloud iam service-accounts add-iam-policy-binding \
    SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=serviceAccount:SERVICE_AGENT_EMAIL \
    --role=roles/iam.serviceAccountTokenCreator

    Ersetzen Sie die folgenden Werte:

    • SERVICE_ACCOUNT_NAME: Der Name des nutzerverwalteten Dienstkontos, das Sie an eine Ressource anhängen.
    • PROJECT_ID: Die Projekt-ID, in der sich das vom Nutzer verwaltete Dienstkonto befindet.
    • SERVICE_AGENT_EMAIL: Die E-Mail-Adresse des Dienstkontos.

    Der Befehl gibt die aktualisierte „allow”-Richtlinie für das vom Nutzer verwaltete Dienstkonto aus.

    Optional: Wenn Sie die Rolle einem anderen Dienst-Agent zuweisen möchten, führen Sie den Befehl noch einmal aus.

    REST

    Verwenden Sie zum Zuweisen dieser Rolle das Read-Modify-Write-Muster, um die „allow”-Richtlinie für Ihr vom Nutzer verwaltetes Dienstkonto zu aktualisieren.

    Lesen Sie als Erstes die „allow”-Richtlinie für das vom Nutzer verwaltete Dienstkonto:

    Die Methode projects.serviceAccounts.getIamPolicy gibt die „allow”-Richtlinie für das Dienstkonto zurück.

    Ersetzen Sie diese Werte in den folgenden Anfragedaten:

    • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
    • USER_SA_NAME: Der Name des nutzerverwalteten Dienstkontos, das Sie an eine Ressource binden.

    HTTP-Methode und URL:

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.iam.gserviceaccount.com:getIamPolicy

    JSON-Text anfordern:

    {
  "requestedPolicyVersion": 3
}

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

    Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

    {
  "version": 1,
  "etag": "BwWl3KCTUMY=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"
      ]
    }
  ]
}

    Ändern Sie als Nächstes die „allow”-Richtlinie, um dem Dienst-Agent die Rolle „Ersteller von Dienstkonto-Tokens” zuzuweisen.

    {
  "version": 1,
  "etag": "BwWl3KCTUMY=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SERVICE_AGENT_EMAIL"
      ]
    },
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com"
      ]
    }
  ]
}

    Ersetzen Sie Folgendes:

    • SERVICE_AGENT_EMAIL: Die E-Mail-Adresse des Dienst-Agents.
    • SERVICE_ACCOUNT_NAME: Der Name des nutzerverwalteten Dienstkontos.
    • PROJECT_ID: Die Projekt-ID, in der sich das vom Nutzer verwaltete Dienstkonto befindet.

    Schreiben Sie anschließend die aktualisierte Zulassungsrichtlinie:

    Die Methode projects.serviceAccounts.setIamPolicy aktualisiert die „allow”-Richtlinie für Ihr Dienstkonto.

    Ersetzen Sie diese Werte in den folgenden Anfragedaten:

    • PROJECT_ID: Ihre Google Cloud-Projekt-ID. Projekt-IDs sind alphanumerische Strings, wie my-project.
    • USER_SERVICE_ACCOUNT_NAME: Der Name des nutzerverwalteten Dienstkontos, das Sie an eine Ressource binden.
    • SERVICE_AGENT_EMAIL: Die E-Mail-Adresse des Dienst-Agents, der die Zugriffstokens für Ihr nutzerverwaltetes Dienstkonto erstellt.

    HTTP-Methode und URL:

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy

    JSON-Text anfordern:

    {
  "policy": {
    "version": 1,
    "etag": "BwWl3KCTUMY=",
    "bindings": [
      {
        "role": "roles/iam.serviceAccountTokenCreator",
        "members": [
          "serviceAccount:SERVICE_AGENT_EMAIL"
        ]
      },
      {
        "role": "roles/iam.serviceAccountUser",
        "members": [
          "serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com"
        ]
      }
    ]
  }
}

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

    Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

    {
  "version": 1,
  "etag": "BwWo331TkHE=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SERVICE_AGENT_EMAIL"
      ]
    },
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"
      ]
    }
  ]
}

Dienstkonto an die neue Ressource anhängen

Nachdem Sie das nutzerverwaltete Dienstkonto konfiguriert haben, können Sie eine neue Ressource erstellen und das Dienstkonto an diese Ressource anhängen. Achten Sie darauf, dass Sie die neue Ressource im entsprechenden Projekt erstellen.

Weitere Informationen finden Sie in der Anleitung für den Ressourcentyp, den Sie erstellen möchten:

Dienstkonto beim Erstellen einer Ressource anhängen
AI Platform Prediction Modellversionen
AI Platform Training Jobs
App Engine-Standardumgebung App-Versionen
Flexible App Engine-Umgebung App-Versionen
Cloud Composer Umgebungen
Cloud Functions Cloud Functions-Funktion
Cloud Life Sciences Pipelines
Cloud Run Services
Cloud Scheduler Jobs
Cloud Quell-Repositories
Compute Engine
Dataflow Jobs
Datalab Instanzen
Dataproc Cluster
Eventarc Trigger
Google Kubernetes Engine
Notebooks Notebookinstanzen
Pub/Sub Abos
Vertex AI
Workflows Workflows

Nachdem Sie die Ressource erstellt und das Dienstkonto an diese Ressource angehängt haben, können Sie dem Dienstkonto Rollen zuweisen, damit es auf die entsprechenden Ressourcen zugreifen kann. Dieser Vorgang ist derselbe wie das Zuweisen einer Rolle an andere Hauptkonten.

Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen.

Dienstkonto an eine Ressource in einem anderen Projekt anhängen

Standardmäßig können Sie ein Dienstkonto nicht in einem Projekt erstellen und es mit einer Ressource in einem anderen Projekt verknüpfen. Wenn Sie alle Dienstkonten in einem Projekt behalten möchten, müssen Sie die Organisationsrichtlinie für dieses Projekt aktualisieren.

Ermöglichen, dass Dienstkonten projektübergreifend angehängt werden können

Damit Nutzer Dienstkonten in einem Projekt an Ressourcen in einem anderen Projekt anhängen können, prüfen Sie die folgenden booleschen Einschränkungen in der Organisationsrichtlinie für das Projekt, in dem sich Ihre Dienstkonten befinden:

  • Achten Sie darauf, dass die boolesche Einschränkung iam.disableCrossProjectServiceAccountUsage für das Projekt nicht erzwungen wird.

    Diese boolesche Einschränkung steuert, ob Sie ein Dienstkonto an eine Ressource in einem anderen Projekt anhängen können. Die Einschränkung wird standardmäßig erzwungen.

    Wenn diese Einschränkung nicht erzwungen wird, fügt IAM eine Projektsperre hinzu, die das Löschen des Projekts verhindert. Diese Sperre hat den Ursprung iam.googleapis.com/cross-project-service-accounts. Wir raten Ihnen dringend davon ab, diese Sperre zu löschen.

  • Empfohlen: Achten Sie darauf, dass die boolesche Einschränkung iam.restrictCrossProjectServiceAccountLienRemoval für das Projekt erzwungen wird.

    Diese boolesche Einschränkung sorgt dafür, dass Hauptkonten die Projektsperre nur dann entfernen können, wenn sie auf Organisationsebene die Berechtigung resourcemanager.projects.updateLiens haben. Wenn diese Einschränkung nicht erzwungen wird, können Hauptkonten die Projektsperre entfernen, wenn sie die Berechtigung auf Projektebene haben.

Informationen zum Anzeigen oder Ändern einer booleschen Einschränkung in einer Organisationsrichtlinie finden Sie unter Organisationsrichtlinien erstellen und verwalten.

Deaktivieren, dass Dienstkonten projektübergreifend angehängt werden können

Wenn Sie zuvor das projektübergreifende Anhängen von Dienstkonten aktiviert haben, raten wir Ihnen dringend davon ab, diese Funktion zu deaktivieren, insbesondere in Produktionsumgebungen.

Insbesondere sollten Sie in dem Projekt, in dem sich Ihre Dienstkonten befinden, keine dieser Änderungen vornehmen:

  • Aktualisieren Sie nicht die Organisationsrichtlinie des Projekts, um die boolesche Einschränkung iam.disableCrossProjectServiceAccountUsage zu erzwingen.
  • Aktualisieren Sie die Organisationsrichtlinie des Projekts nicht, um die boolesche Einschränkung iam.restrictCrossProjectServiceAccountLienRemoval nicht zu erzwingen.
  • Entfernen Sie die Projektsperre mit dem Ursprung iam.googleapis.com/cross-project-service-accounts nicht, welche verhindert, dass das Projekt gelöscht werden kann.
  • Löschen Sie das Projekt nicht.

Wenn Sie bereit sind, die Risiken dieser Funktion anzunehmen, können Sie die Dienstkonten deaktivieren, die Sie projektübergreifend verwenden. Danach überwachen Sie Ihre Google Cloud-Umgebung für Probleme. Sollten Sie Probleme feststellen, können Sie die Dienstkonten wieder aktivieren. Wenn Sie keine Probleme sehen, haben Sie möglicherweise keine Google Cloud-Ressourcen, die von einem Dienstkonto in einem anderen Projekt abhängen.

Nächste Schritte