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 Dataflow Dataproc	Nutzer können das Compute Engine-Standarddienstkonto an Ressourcen anhängen, auch wenn sie nicht berechtigt sind, die Identität des Standarddienstkontos zu übernehmen.

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.

Optional: Verwenden Sie Rollenempfehlungen, um die 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.
Hinweis: Zum weiteren Schutz Ihrer Organisation können Sie die automatische Rollenzuweisung für Standarddienstkonten deaktivieren.
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 finden Sie unter Identitätswechsel für Dienstkonten verwalten.
Hinweis: Wenn Sie eine große Anzahl an Projekten haben, können Sie mit der Suche nach Berechtigungsabweichungen die Nutzer ermitteln, die eine Berechtigung zum Bereitstellen von Anwendungen, aber nicht zum Übernehmen der Identität des App Engine-Standarddienstkontos haben.
Aktivieren Sie die Richtlinieneinschränkung auf Organisationsebene constraints/appengine.enforceServiceAccountActAsCheck, um beim Bereitstellen von Anwendungen die Prüfung der Kontoberechtigung zu erzwingen.

Hinweis: Diese Einschränkung der Organisationsrichtlinie ist nur in Umgebungen mit dem alten Verhalten sichtbar. Wenn die Einschränkung nicht angezeigt wird, ist die Einschränkung bereits in Ihrer Umgebung erzwungen.
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.

Ermitteln Sie alle Dienstkonten, die an Cloud Composer-Umgebungen gebunden sind:
1. Rufen Sie in der Google 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.
Bestätigen Sie, dass diese Dienstkonten dem Prinzip der geringsten Berechtigung folgen:
- Rufen Sie in der Google Cloud Console die Seite IAM auf, suchen Sie nach den Dienstkonten und überprüfen Sie deren Rollen.
  
  Zur Seite "IAM"
- Gewähren Sie dem Dienstkonto gegebenenfalls eine weniger freizügige Rolle. Sie können eine Rolle aus der Liste auswählen:Vordefinierte IAM-Rollen verwenden Sie eine Rolle, die Rollenempfehlung oder erstellen Sie einbenutzerdefinierte Rolle.
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.
Hinweis: Wenn Sie eine große Anzahl an Projekten haben, können Sie mit der Suche nach Berechtigungsabweichungen die Nutzer ermitteln, die eine Berechtigung zum Bereitstellen von Cloud Composer-Umgebungen, aber nicht zum Übernehmen der Identität von Dienstkonten haben.
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.

Hinweis: Diese Einschränkung der Organisationsrichtlinie ist nur in Umgebungen mit dem alten Verhalten sichtbar. Wenn die Einschränkung nicht angezeigt wird, ist die Einschränkung bereits in Ihrer Umgebung erzwungen.
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:

Hinweis: In Cloud Data Fusion ist die Verwendung von anderen Dienstkonten als dem Compute Engine-Standarddienstkonto nur für Kunden von Cloud Data Fusion Enterprise verfügbar. Weitere Informationen finden Sie unter Cloud Data Fusion-Dienstkonten.
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:
  - Dataproc-Dienstkontoanforderungen
  - Dataflow-Dienstkontoanforderungen
  - Cloud Data Fusion-Dienstkonten haben die gleichen Anforderungen wie Dataproc-Dienstkonten.
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 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
  constraints/dataproc.enforceComputeDefaultServiceAccountCheck Die Richtlinieneinschränkung auf Organisationsebene erzwingt auch Berechtigungsprüfungen für Cloud Data Fusion.
  
  Hinweis: Diese Einschränkungen für Organisationsrichtlinien sind nur in Umgebungen mit dem Legacy-Verhalten sichtbar. Wenn Sie die Einschränkungen nicht sehen, werden die Einschränkungen bereits in Ihrer Umgebung erzwungen.
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 Rollenempfehlungen, 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.
  Hinweis: Zum weiteren Schutz Ihrer Organisation können Sie die automatische Rollenzuweisung für Standarddienstkonten deaktivieren.
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.
  Hinweis: Wenn Sie eine große Anzahl an Projekten haben, können Sie mit der Suche nach Berechtigungsabweichungen die Nutzer ermitteln, die eine Berechtigung zum Bereitstellen von Ressourcen, aber nicht zum Übernehmen der Identität des Compute Engine-Standarddienstkontos haben.
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.