Berechtigung zum Anhängen von Dienstkonten an Ressourcen erfordern

Beim Erstellen bestimmter Google Cloud-Ressourcen haben Sie die Möglichkeit, ein Dienstkonto anzuhängen. Das angehängte Dienstkonto fungiert als Identität für alle Jobs, die auf der Ressource ausgeführt werden. Dadurch können sich die Jobs bei Google Cloud APIs authentifizieren.

Bei den meisten Google Cloud-Diensten benötigen Nutzer die Berechtigung, die Identität eines Dienstkontos zu übernehmen, um dieses Dienstkonto an eine Ressource anhängen zu können. Dies bedeutet, dass der Nutzer die Berechtigung iam.serviceAccounts.actAs für das Dienstkonto benötigt.

In der Vergangenheit erlaubten es jedoch bestimmte Dienste den Nutzern, Dienstkonten an Ressourcen anzuhängen, selbst wenn die Nutzer nicht die Erlaubnis hatten, sich als die Dienstkonten auszugeben. Diese Konfiguration könnte es den Nutzern dieser Dienste ermöglicht haben, erhöhte, nicht offensichtliche Berechtigungen zu erhalten.

In der folgenden Tabelle sind die Dienste, die diese Konfiguration hatten, zusammen mit dem bisherigen Verhalten jedes Dienstes aufgeführt:

Dienst Bisheriges Verhalten
App Engine Nutzer können App Engine-Anwendungen bereitstellen, die die Identität des App Engine-Standarddienstkontos verwenden, auch wenn sie nicht die Berechtigung haben, die Identität des App Engine-Standarddienstkontos zu übernehmen.
Cloud Composer Nutzer können beliebige Dienstkonten im Projekt an eine Cloud Composer-Umgebung anhängen, auch wenn sie nicht berechtigt sind, die Identität eines beliebigen Dienstkontos zu übernehmen.
Cloud Data Fusion Nutzer können das Compute Engine-Standarddienstkonto an Ressourcen anhängen, auch wenn sie nicht berechtigt sind, die Identität des Standarddienstkontos zu übernehmen.
Dataflow
Dataproc

Jetzt müssen diese Dienste prüfen, ob Nutzer die Berechtigung haben, die Identität von Dienstkonten zu übernehmen, wenn sie die Dienstkonten an Ressourcen anhängen. Das bisherige Verhalten besteht jedoch weiterhin für folgende Arten von Organisationen:

  • Organisationen mit Nutzern, die die Berechtigung zum Bereitstellen von App Engine-Anwendungen haben, aber nicht berechtigt sind, die Identität des App Engine-Standarddienstkontos zu übernehmen.
  • Organisationen mit Nutzern, die berechtigt sind, Cloud Composer-Umgebungen bereitzustellen, aber nicht berechtigt sind, die Identität eines Dienstkontos zu übernehmen.
  • Organisationen mit Nutzern, die berechtigt sind, Cloud Data Fusion-, Dataflow- oder Dataproc-Ressourcen bereitzustellen, aber nicht berechtigt sind, die Identität des Compute Engine-Standarddienstkontos zu übernehmen.

Wenn Ihre Organisation weiterhin vom bisherigen Verhalten betroffen ist, haben Sie eine Mitteilung erhalten, die erläutert, wie Sie es manuell deaktivieren können. Eine detaillierte Anleitung dazu finden Sie auch in den folgenden Abschnitten.

App Engine schützen

Damit Nutzer das bisherige Verhalten für App Engine manuell deaktivieren können, müssen sie berechtigt sein, die Identität des App Engine-Dienstkontos zu übernehmen. Aktivieren Sie dafür eine Richtlinieneinschränkung auf Organisationsebene, um eine Prüfung der Dienstkontoberechtigung zu erzwingen, wenn Anwendungen bereitgestellt werden, die die Identität des App Engine-Standarddienstkontos verwenden.

  1. Optional: Verwenden Sie den IAM Recommender, um Berechtigungen für das App Engine-Standarddienstkonto wirksam herabzustufen.

    Dem App Engine-Standarddienstkonto wird automatisch die sehr weitreichende Bearbeiterrolle (roles/editor) zugewiesen. Es wird jedoch empfohlen, eine solche Rolle nicht in Produktionskonfigurationen zu verwenden.

  2. Alle Nutzer, die Anwendungen bereitstellen, müssen die Identität des App Engine-Standarddienstkontos übernehmen können.

    Weisen Sie den Nutzern daher eine Rolle mit der Berechtigung iam.serviceAccounts.actAs zu, z. B. die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser). Sie können diese Rolle für das Projekt oder für das App Engine-Standarddienstkonto zuweisen. Eine Anleitung dazu finden Sie unter Identitätswechsel für Dienstkonten verwalten.

  3. Aktivieren Sie die Richtlinieneinschränkung auf Organisationsebene constraints/appengine.enforceServiceAccountActAsCheck, um beim Bereitstellen von Anwendungen die Prüfung der Kontoberechtigung zu erzwingen.

  4. Optional: Mit der Erzwingung boolescher Organisationsrichtlinien können Sie prüfen, ob die Richtlinieneinschränkung auf Organisationsebene für alle Projekte gilt.

Cloud Composer schützen

Wenn Sie das bisherige Verhalten für Cloud Composer manuell deaktivieren möchten, sollten Sie prüfen, ob die Nutzer die Berechtigung für die Übernahme der Identität der Dienstkonten haben, die sie an neue Umgebungen anhängen. Aktivieren Sie dann eine Richtlinieneinschränkung auf Organisationsebene, um beim Anhängen von Dienstkonten an Umgebungen eine Prüfung der Dienstkontoberechtigung zu erzwingen.

  1. Ermitteln Sie alle Dienstkonten, die an Cloud Composer-Umgebungen gebunden sind:

    1. Rufen Sie in der Cloud Console die Seite Composer-Umgebungen auf.

      Zur Seite "Composer-Umgebungen"

    2. Klicken Sie auf den Namen einer Umgebung.

    3. Suchen Sie im Tab Umgebungskonfiguration nach dem Feld Dienstkonto und notieren Sie sich den Namen des Dienstkontos.

    4. Wiederholen Sie die vorherigen Schritte für alle Cloud Composer-Umgebungen im Projekt.

  2. Bestätigen Sie, dass diese Dienstkonten dem Prinzip der geringsten Berechtigung folgen:

  3. Sorgen Sie dafür, dass alle Nutzer, die Cloud Composer-Umgebungen bereitstellen oder verwalten, die Identität der Dienstkonten übernehmen können, die von den Umgebungen verwendet werden.

    Weisen Sie den Nutzern daher eine Rolle mit der Berechtigung iam.serviceAccounts.actAs zu, z. B. die Rolle "Dienstkontonutzer" (roles/iam.serviceAccountUser). Sie können diese Rolle für das Projekt oder für ein einzelnes Dienstkonto zuweisen. Eine Anleitung finden Sie unter Identitätswechsel für Dienstkonten verwalten.

  4. Aktivieren Sie die Richtlinieneinschränkung auf Organisationsebene constraints/composer.enforceServiceAccountActAsCheck, um beim Anhängen von Dienstkonten an Umgebungen eine Prüfung der Kontoberechtigung zu erzwingen.

  5. Optional: Mit der Erzwingung boolescher Organisationsrichtlinien können Sie prüfen, ob die Richtlinieneinschränkung auf Organisationsebene für alle Projekte gilt.

Dataproc, Dataflow und Cloud Data Fusion schützen

Wenn Sie das bisherige Verhalten für Dataproc, Dataflow und Cloud Data Fusion manuell deaktivieren möchten, sollten Sie prüfen, ob die Nutzer die Berechtigung für die Übernahme der Identität der Dienstkonten haben, die sie an neue Ressourcen anhängen. Aktivieren Sie dann Richtlinieneinschränkungen auf Organisationsebene, um beim Anhängen von Dienstkonten an Ressourcen eine Prüfung der Kontoberechtigung zu erzwingen.

Folgen Sie der Anleitung für den Dienstkontotyp, den Sie an neue Ressourcen anhängen möchten:

  • Wenn Sie die Verknüpfung des Compute Engine-Standarddienstkontos an neue Ressourcen beenden möchten, führen Sie die folgenden Schritte aus:

    1. Erstellen Sie ein neues Dienstkonto und gewähren Sie dem Dienstkonto die Rollen, die zum Ausführen von Jobs für die Ressource erforderlich sind. Beachten Sie das Prinzip der geringsten Berechtigung.

      Informationen dazu, welche Rollen ein Dienstkonto zum Ausführen von Jobs in Dataproc, Dataflow und Cloud Data Fusion benötigt, finden Sie hier:

    2. Erlauben Sie allen Nutzern, die diese Ressourcen bereitstellen, die Übernahme der Identität des neuen Dienstkontos.

      Erteilen Sie Nutzern hierfür eine Rolle mit der Berechtigung iam.serviceAccounts.actAs, z. B. die Rolle "Dienstkontonutzer" (roles/iam.serviceAccountUser). Sie können diese Rolle für das Projekt oder das Dienstkonto zuweisen. Eine Anleitung dazu finden Sie unter Identitätswechsel für Dienstkonten verwalten.

    3. Aktivieren Sie die folgenden Richtlinieneinschränkungen auf Organisationsebene, um beim Anhängen von Dienstkonten an Ressourcen eine Prüfung der Kontoberechtigung zu erzwingen:

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck
    4. Optional: Mit der Erzwingung boolescher Organisationsrichtlinien können Sie prüfen, ob die Richtlinieneinschränkung auf Organisationsebene für alle Projekte gilt.

    5. Verwenden Sie beim Bereitstellen neuer Ressourcen das neue Dienstkonto anstelle des Compute Engine-Standarddienstkontos.

  • Wenn Sie das Compute Engine-Standarddienstkonto weiterhin an neue Ressourcen anhängen möchten, gehen Sie so vor:

    1. Optional: Verwenden Sie den IAM Recommender, um Berechtigungen für das Compute Engine-Standarddienstkonto wirksam zu herabzustufen.

      Dem Compute Engine-Standarddienstkonto wird automatisch die sehr weitreichende Bearbeiterrolle (roles/editor) zugewiesen. Es wird jedoch empfohlen, eine solche Rolle nicht in Produktionskonfigurationen zu verwenden.

    2. Sorgen Sie dafür, dass alle Nutzer, die diese Ressourcen bereitstellen, die Möglichkeit haben, die Identität des Compute Engine-Standarddienstkontos zu übernehmen.

      Weisen Sie den Nutzern daher eine Rolle mit der Berechtigung iam.serviceAccounts.actAs zu, z. B. die Rolle "Dienstkontonutzer" (roles/iam.serviceAccountUser). Sie können diese Rolle für das Projekt oder das Compute Engine-Standarddienstkonto erteilen. Eine Anleitung finden Sie unter Identitätswechsel für Dienstkonten verwalten.

    3. Aktivieren Sie die folgenden Richtlinieneinschränkungen auf Organisationsebene, um beim Anhängen von Dienstkonten an Ressourcen eine Prüfung der Kontoberechtigung zu erzwingen:

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck
    4. Optional: Mit der Erzwingung boolescher Organisationsrichtlinien können Sie prüfen, ob die Richtlinieneinschränkung auf Organisationsebene für alle Projekte gilt.