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 APIs authentifizieren. Google Cloud

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. Das 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.
Managed Service for Apache Airflow Nutzer können beliebige Dienstkonten im Projekt an eine Managed Airflow-Umgebung anhängen, auch wenn sie nicht berechtigt sind, die Identität eines beliebigen Dienstkontos zu übernehmen.
  • Cloud Data Fusion
  • Dataflow
  • Managed Service for Apache Spark
 Nutzer können das Compute Engine-Standarddienstkonto an Ressourcen anhängen, auch wenn sie nicht berechtigt sind, die Identität des Standarddienstkontos zu übernehmen.
Dataform Nutzer können ein Dienstkonto an eine Dataform-Ressource anhängen und eine Workflow-Ausführung erstellen, die als dieses Dienstkonto ausgeführt wird, auch wenn sie nicht berechtigt sind, die Identität des Dienstkontos 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, Managed Airflow-Umgebungen bereitzustellen, aber nicht berechtigt sind, die Identität eines Dienstkontos zu übernehmen.
  • Organisationen mit Nutzern, die berechtigt sind, Cloud Data Fusion-, Dataflow- oder Managed Service for Apache Spark-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 Rollenempfehlungen, um die Berechtigungen für das App Engine-Standarddienstkonto sicher 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 finden Sie unter Identitätsübernahme des Dienstkontos verwalten.

  3. Aktivieren Sie die Organisationsrichtlinieneinschränkung constraints/appengine.enforceServiceAccountActAsCheck, um beim Bereitstellen von Anwendungen die Prüfung der Dienstkontoberechtigungen zu erzwingen.

  4. Optional: Use the boolean organization policy enforcer to confirm that the organization policy constraint is enforced in all of your projects.

Managed Service for Apache Airflow schützen

Wenn Sie das bisherige Verhalten für Managed Airflow 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 Organisationsrichtlinieneinschränkung, um beim Anhängen von Dienstkonten an Umgebungen eine Prüfung der Dienstkontoberechtigungen zu erzwingen.

  1. Ermitteln Sie alle Dienstkonten, die an Managed Airflow-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 Managed Airflow-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 Managed Airflow-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ätsübernahme des Dienstkontos verwalten.

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

  5. Optional: Use the boolean organization policy enforcer to confirm that the organization policy constraint is enforced in all of your projects.

Managed Service for Apache Spark, Dataflow und Cloud Data Fusion schützen

Wenn Sie das bisherige Verhalten für Managed Service for Apache Spark, 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 Managed Service for Apache Spark-, Dataflow- und Cloud Data Fusion-Ressourcen 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 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.

    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-Standarddienst konto 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ätsübernahme des Dienstkontos 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.

Dataform schützen

Wenn Sie das bisherige Verhalten für Dataform 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 Dataform-Ressourcen anhängen.

  1. Prüfen Sie auf Berechtigungsprobleme, um Unterbrechungen Ihrer Workflows zu vermeiden. Dazu können Sie Cloud Logging nach Dataform-spezifischen Einträgen durchsuchen, die darauf hinweisen, dass einem Hauptkonto (Nutzer oder Dienstkonto) die erforderliche Berechtigung iam.serviceAccounts.actAs fehlt. So können Sie Zugriffsunterschiede proaktiv erkennen und beheben. Weitere Informationen finden Sie unter In Cloud Logging nach Berechtigungsproblemen suchen.

  2. Gewähren Sie Nutzern oder Dienstkonten, die Workflow-Aufrufe erstellen müssen, die Berechtigung, die Identität des Dienstkontos zu übernehmen, das mit dem Dataform-Repository verknüpft ist. Sie können diese Berechtigung erteilen, indem Sie die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser) für das jeweilige Dienstkonto zuweisen. Weitere Informationen finden Sie unter Berechtigungsprobleme beheben.

  3. Wenn Sie ein benutzerdefiniertes Dienstkonto verwenden, weisen Sie dem Standard-Dataform-Dienst-Agenten für das benutzerdefinierte Dienstkonto die folgenden Rollen zu:

    • Ersteller von Dienstkonto-Tokens (roles/iam.serviceAccountTokenCreator): Für alle Repository Vorgänge, die ein benutzerdefiniertes Dienstkonto verwenden, erforderlich.
    • Dienstkontonutzer (roles/iam.serviceAccountUser): Nur erforderlich, wenn Sie Workflow Konfigurationen verwenden, um Ausführungen zu planen oder zu automatisieren. Mit dieser Rolle kann der Standard-Dataform-Dienstkontoagent Aufgaben als benutzerdefiniertes Dienstkonto ausführen.

  4. Prüfen Sie regelmäßig Ihre Dataform-Ressourcen, um die ordnungsgemäße Verwendung von Dienstkonten und die Berechtigungsvergabe sicherzustellen. Verwenden Sie Cloud Asset Inventory, um alle Ressourcen der Typen dataform.Repository und dataform.WorkflowConfig aufzulisten, und prüfen Sie dann das Feld resource.data.serviceAccount, um zu sehen, welches Dienstkonto verwendet wird. Wenn ein benutzerdefiniertes Dienstkonto verwendet wird, prüfen Sie, ob der Standard-Dataform-Dienstkontoagent für dieses benutzerdefinierte Dienstkonto sowohl die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser) als auch die Rolle „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator) hat. Weitere Informationen finden Sie unter Dienstkontokonfigurationen prüfen.