Dienstkonten

Auf dieser Seite wird beschrieben, wie Dienstkonten mit Compute Engine verwendet werden.

Eine schrittweise Anleitung zum Anhängen eines Dienstkontos an eine VM-Instanz finden Sie in einem der folgenden Dokumente:

Informationen zu Best Practices für das Erstellen und Verwalten von Dienstkonten finden Sie in der Dokumentation zu Best Practices für die Arbeit mit Dienstkonten.

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit von Compute Engine in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Compute Engine kostenlos testen

Was ist ein Dienstkonto?

Ein Dienstkonto ist ein spezieller Kontotyp, der nicht von einer Person, sondern von einer Anwendung oder einer Compute-Arbeitslast verwendet wird. Dienstkonten werden vom IAM (Identity and Access Management) verwaltet.

Beachten Sie bei der Verwendung von Dienstkonten mit Ihren VMs Folgendes:

  • Sie können dasselbe Dienstkonto an mehrere VMs anhängen, an eine einzelne VM kann jedoch nur ein Dienstkonto angehängt werden.
  • Wenn Sie dasselbe Dienstkonto an mehrere VMs anhängen, wirken sich nachfolgende Änderungen am Dienstkonto auf alle VMs aus, die das Dienstkonto verwenden. Dies schließt alle Änderungen an IAM-Rollen ein, die Sie dem Dienstkonto gewährt haben. Wenn Sie zum Beispiel eine Rolle entfernen, verlieren alle VMs, die das Dienstkonto verwenden, die durch diese Rolle gewährten Berechtigungen.

So werden Dienstkonten in Compute Engine verwendet

In Compute Engine werden zwei Arten von Dienstkonten verwendet:

Ein vom Nutzer verwaltetes Dienstkonto kann an eine Compute Engine-Instanz angehängt werden, um Anmeldedaten für Anwendungen bereitzustellen, die auf der Instanz ausgeführt werden. Diese Anmeldedaten werden von der Anwendung für die Authentifizierung bei Google Cloud APIs und die Autorisierung für den Zugriff auf Google Cloud-Ressourcen verwendet. Nur nutzerverwaltete Dienstkonten können an eine Instanz angehängt werden und eine Instanz kann nur ein angehängtes Dienstkonto haben. Sie können das Dienstkonto, das einer Instanz angehängt ist, später bei der Erstellung ändern.

Dienst-Agents werden von der Instanz verwendet, um in Ihrem Namen auf interne Prozesse zuzugreifen.

Außerdem können Sie Firewallregeln erstellen, durch die Traffic zu und von Instanzen entsprechend dem mit ihr verknüpften Dienstkonto zugelassen oder verweigert wird.

So wird Autorisierung bestimmt

Die Autorisierung für Anwendungen, die auf einer Compute Engine-Instanz gehostet werden, wird durch zwei separate Konfigurationen begrenzt: die Rollen, die dem angehängten Dienstkonto zugewiesen wurden und die Zugriffsbereiche, die Sie für die Instanz festgelegt haben. Beide Konfigurationen müssen Zugriff gewähren, damit die auf der Instanz ausgeführte Anwendung auf eine Ressource zugreifen kann.

Wenn Sie eine Anwendung haben, die Dateien in Cloud Storage liest und schreibt, muss sie sich zuerst bei der Cloud Storage API authentifizieren. Sie können eine Instanz mit dem Bereich cloud-platform erstellen und ein Dienstkonto an die Instanz anhängen. Sie können dem Dienstkonto dann IAM-Rollen (Identity and Access Management) zuweisen, damit Ihre Anwendung Zugriff auf die entsprechenden Ressourcen hat. Ihre Anwendung verwendet die Anmeldedaten des Dienstkontos, um sich bei der Cloud Storage API zu authentifizieren, ohne Secret-Schlüssel oder Nutzeranmeldedaten in Ihre Instanz, Ihr Image oder Ihren Anwendungscode einzubinden. Ihre Anwendung verwendet auch die von den IAM-Rollen des Dienstkontos bereitgestellte Autorisierung für den Zugriff auf Ressourcen. Weitere Informationen zur Autorisierung finden Sie auf dieser Seite unter Autorisierung.

Nutzerverwaltete Dienstkonten

Zu den nutzerverwalteten Dienstkonten gehören neue Dienstkonten, die Sie explizit erstellen, und das standardmäßige Compute Engine-Dienstkonto.

Neue Dienstkonten

Sie können Ihre Dienstkonten mit IAM erstellen und verwalten. Nachdem Sie ein Konto erstellt haben, weisen Sie ihm IAM-Rollen zu und richten Instanzen so ein, dass sie als das Dienstkonto ausgeführt werden. Anwendungen, die auf Instanzen mit dem angehängten Dienstkonto ausgeführt werden, können unter Einsatz der Anmeldedaten des Kontos Anfragen an andere Google APIs senden.

Informationen zum Erstellen und Einrichten eines neuen Dienstkontos finden Sie unter VM erstellen, die nutzerverwaltetem Dienstkonto nutzt.

Standardmäßiges Compute Engine-Dienstkonto

Neue Projekte, für die die Compute Engine API aktiviert ist, haben ein Compute Engine-Standarddienstkonto mit der folgenden E-Mail-Adresse:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Das Compute Engine-Standarddienstkonto hat die folgenden Attribute:

  • Es wird automatisch mit einem automatisch generierten Namen und einer E-Mail-Adresse erstellt und Ihrem Projekt hinzugefügt, wenn Sie die Compute Engine API aktivieren. Sie haben die volle Kontrolle über das Konto.
  • Es wird standardmäßig an alle VMs angehängt, die Sie mit der Google Cloud CLI oder der Google Cloud Console erstellt haben. Dieses Verhalten lässt sich überschreiben, indem Sie beim Erstellen der VM ein anderes Dienstkonto angeben oder explizit angeben, dass der VM kein Dienstkonto zugeordnet werden soll.

  • Abhängig von der Konfiguration Ihrer Organisationsrichtlinie kann dem Standarddienstkonto für Ihr Projekt automatisch die Rolle "Bearbeiter" zugewiesen werden. Wir empfehlen dringend, die automatische Rollenzuweisung zu deaktivieren, indem Sie die Einschränkung der Organisationsrichtlinien iam.automaticIamGrantsForDefaultServiceAccounts erzwingen. Wenn Sie Ihre Organisation nach dem 3. Mai 2024 erstellt haben, wird diese Einschränkung standardmäßig erzwungen.

    Wenn Sie die automatische Rollenzuweisung deaktivieren, müssen Sie entscheiden, welche Rollen den Standarddienstkonten zugeteilt werden sollen, und diese Rollen dann selbst zuweisen.

    Wenn das Standarddienstkonto bereits die Rolle "Bearbeiter" hat, sollten Sie die Rolle "Bearbeiter" durch weniger strikte Rollen ersetzen. Verwenden Sie zum sicheren Ändern der Rollen des Dienstkontos Policy Simulator, um die Auswirkungen der Änderung zu sehen, und weisen Sie die entsprechenden Rollen zu und widerrufen Sie sie.

Sie haben die Möglichkeit, dieses Dienstkonto zu deaktivieren oder aus Ihrem Projekt zu löschen. Das kann aber dazu führen, dass alle Anwendungen fehlschlagen, die auf die Anmeldedaten des Dienstkontos angewiesen sind. Wenn Sie das Compute Engine-Standarddienstkonto versehentlich löschen, können Sie es innerhalb von 30 Tagen wiederherstellen. Weitere Informationen finden Sie unter Dienstkonten löschen und wiederherstellen.

Wenn das Compute Engine-Standarddienstkonto vor mehr als 30 Tagen gelöscht wurde, können Sie versuchen, das Dienstkonto wiederherzustellen. Folgen Sie dazu dem Prozess unter Fehlerbehebung bei Standarddienstkonten.

Kundenservicemitarbeiter

Dienst-Agents werden von Google Cloud erstellt und verwaltet und Ihrem Projekt automatisch zugewiesen. Diese Konten repräsentieren verschiedene Google Cloud-Dienste. Jedes einzelne Konto hat normalerweise einen gewissen Zugriff auf Ihre Google Cloud-Ressourcen.

Sie können einer Compute Engine-Instanz keine Dienst-Agents hinzufügen.

Google APIs-Dienst-Agent

Neben dem Standarddienstkonto haben alle Projekte, die mit der Compute Engine aktiviert wurden, ein Google APIs-Dienst-Agent, das an dieser E-Mail erkennbar ist:

PROJECT_NUMBER@cloudservices.gserviceaccount.com

Dieser Dienst-Agent ist speziell dafür vorgesehen, interne Google-Prozesse in Ihrem Namen auszuführen. Der Dienst-Agent ist Eigentum von Google und ist nicht im Abschnitt Dienstkonten der Google Cloud Console aufgeführt. Standardmäßig wird dem Dienst-Agent automatisch die Rolle „Project Editor“ für das Projekt zugewiesen. Weiter wird er in der Console im Bereich IAM aufgeführt. Dieser Dienst-Agent wird nur gelöscht, wenn das Projekt gelöscht wird. Allerdings können Sie die Rollen ändern, die diesem Konto zugewiesen sind. Sie können ihm auch jeden Zugriff auf Ihr Projekt entziehen.

Bestimmte Ressourcen sind darauf angewiesen, dass dem Dienst-Agent die Standardberechtigungen zugewiesen wurden. So nutzen zum Beispiel verwaltete Instanzgruppen und die automatische Skalierung die Anmeldedaten dieses Dienst-Agents, um Instanzen zu erstellen, zu löschen und zu verwalten. Wenn Sie diesem Dienst-Agent Berechtigungen entziehen oder seine Berechtigungen so ändern, dass er keine Instanzen mehr erstellen kann, wird dies dazu führen, dass verwaltete Instanzgruppen und die automatische Skalierung nicht mehr funktionieren.

Aus diesen Gründen sollten Sie die Rollen dieses Dienst-Agents nur ändern, wenn eine Rollenempfehlung ausdrücklich vorschlägt, dass Sie sie ändern.

Compute Engine-Dienst-Agent

Alle Projekte, für die die Compute Engine API aktiviert ist, haben ein Compute Engine-Dienst-Agent mit der folgenden E-Mail-Adresse:

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

Dieser Dienst-Agent wurde speziell für Compute Engine entwickelt, um Dienstaufgaben für Ihr Projekt auszuführen. Es basiert auf der IAM-Richtlinie "Dienstagent", die Ihrem Google Cloud-Projekt zugewiesen wurde. Es ist auch der Dienst-Agent, mit dem Compute Engine auf das nutzerverwaltete Dienstkonto auf VM-Instanzen zugreift. Google ist zwar der Inhaber dieses Kontos, das Konto ist aber für Ihr Projekt spezifisch. Dieser Dienst-Agent wird auf der IAM-Seite der Console ausgeblendet, es sei denn, Sie wählen Von Google bereitgestellte Rollenzuweisungen einschließen aus. Standardmäßig wird diesem Dienst-Agent in Ihrem Projekt automatisch die Rolle compute.serviceAgent zugewiesen.

Dieser Dienst-Agent wird nur gelöscht, wenn Sie Ihr Projekt löschen. Sie können die diesem Dienst-Agent zugewiesenen Rollen ändern und ihm auch jeglichen gesamten Zugriff auf Ihr Projekt entziehen. Durch den Widerruf oder die Änderung der Berechtigungen für diesen Dienst-Agent wird verhindert, dass Compute Engine die Dienstkonten-Identitäten auf Ihren VMs verwenden kann. Dies kann zu Softwareausfällen in Ihren VMs führen.

Aus diesen Gründen sollten Sie die Rollen dieses Dienst-Agents möglichst nicht ändern.

Dienstkonto an eine Instanz anhängen

Damit Sie einer Anwendung nicht übermäßig viele Berechtigungen zuweisen, sollten Sie ein nutzerverwaltetes Dienstkonto erstellen, diesem nur die Rollen zuweisen, die Ihre Anwendung für eine ordnungsgemäße Funktionsweise benötigt, und es an Ihre Compute Engine-Instanz anhängen. Ihr Code kann sich dann mit Standardanmeldedaten für Anwendungen mit den vom Dienstkonto bereitgestellten Anmeldedaten authentifizieren.

Sie können einer Compute Engine-Instanz ein Dienstkonto hinzufügen, wenn Sie die Instanz erstellen oder zu einem späteren Zeitpunkt. Es kann jeweils nur ein Dienstkonto an eine Instanz angehängt werden. Wenn Sie ein Dienstkonto an eine Instanz anhängen, an die bereits ein Dienstkonto angehängt ist, wird das vorherige Dienstkonto nicht mehr von dieser Instanz verwendet.

Wenn Sie ein Dienstkonto an eine Compute Engine-Instanz anhängen, müssen Sie auch sicherstellen, dass die auf der Instanz festgelegten Bereiche korrekt sind. Andernfalls kann Ihre Anwendung möglicherweise nicht auf alle erforderlichen APIs zugreifen. Weitere Informationen finden Sie auf dieser Seite unter Zugriffsbereiche.

Eine schrittweise Anleitung zum Anhängen eines Dienstkontos an eine Compute Engine-Instanz finden Sie in einem der folgenden Dokumente:

Autorisierung

Wenn Sie eine Instanz für die Ausführung als Dienstkonto einrichten, legen Sie die Zugriffsebene des Dienstkontos anhand der IAM-Rollen fest, die Sie dem Dienstkonto zuweisen. Wenn das Dienstkonto keine IAM-Rollen hat, kann über das Dienstkonto auf dieser Instanz nicht auf Ressourcen zugegriffen werden.

Darüber hinaus werden mit den Zugriffsbereichen einer Instanz die standardmäßigen OAuth-Bereiche für Anfragen festgelegt, die auf der Instanz über die gcloud CLI und Clientbibliotheken erfolgen. Dies hat zur Folge, dass mit Zugriffsbereichen bei der Authentifizierung über OAuth möglicherweise der Zugriff auf API-Methoden eingeschränkt wird. Sie wirken sich jedoch nicht auf andere Authentifizierungsprotokolle wie gRPC aus.

Als Best Practice wird empfohlen, den vollständigen Zugriffsbereich cloud-platform für die Instanz zu verwenden und dann den Zugriff des Dienstkontos mithilfe von IAM-Rollen zu steuern.

Im Wesentlichen:

  • schränkt IAM den Zugriff auf APIs basierend auf den IAM-Rollen ein, die dem Dienstkonto zugewiesen sind;
  • wird mit Zugriffsbereichen der Zugriff auf API-Methoden weiter eingeschränkt.

Zugriffsbereiche und IAM-Rollen werden in den folgenden Abschnitten ausführlich beschrieben.

IAM-Rollen

Sie müssen einem Dienstkonto die entsprechenden IAM-Rollen zuweisen, um dem Dienstkonto Zugriff auf relevante API-Methoden zu gewähren.

Beispielsweise können Sie einem Dienstkonto die IAM-Rollen zur Verwaltung von Cloud Storage-Objekten und/oder zur Verwaltung von Cloud Storage-Buckets zuweisen. Das Konto ist dann auf die Berechtigungen beschränkt, die durch diese Rollen gewährt werden.

Wenn Sie einem Dienstkonto eine IAM-Rolle zuweisen, erhält jede Anwendung, die auf einer Instanz ausgeführt wird, der dieses Dienstkonto zugeordnet ist, die durch diese Rolle gewährte Autorisierung.

Folgende Punkte sollten Sie bedenken:

  • Einige IAM-Rollen sind aktuell in der Betaphase.

    Ist für die gewünschte Zugriffsebene keine vordefinierte Rolle vorhanden, können Sie benutzerdefinierte Rollen erstellen und zuweisen.

  • Sie müssen Zugriffsbereiche auf der Instanz festlegen, um den Zugriff zu autorisieren.

    Die Zugriffsebene eines Dienstkontos wird anhand der Rollen festgelegt, die dem Dienstkonto zugewiesen sind. Mit den Zugriffsbereichen einer Instanz werden die standardmäßigen OAuth-Bereiche für Anfragen festgelegt, die auf der Instanz über die gcloud CLI und Clientbibliotheken erfolgen. Dies hat zur Folge, dass mit Zugriffsbereichen bei der Authentifizierung über OAuth möglicherweise der Zugriff auf API-Methoden eingeschränkt wird.

Zugriffsbereiche

Zugriffsbereiche sind die herkömmliche Methode, die Autorisierung für Ihre Instanz festzulegen. Sie definieren die standardmäßigen OAuth-Bereiche, die in Anfragen über die gcloud CLI oder die Clientbibliotheken verwendet werden. Zugriffsbereiche gelten nicht für Aufrufe, die mit gRPC durchgeführt werden.

Zugriffsbereiche gelten jeweils für eine VM und bleiben nur für die Lebensdauer der VM bestehen. Sie können beim Erstellen einer VM Zugriffsbereiche festlegen oder den Zugriffsbereich einer vorhandenen VM aktualisieren.

Im Allgemeinen werden in der Dokumentation für jede API-Methode die für diese Methode erforderlichen Bereiche aufgeführt. So wird beispielsweise mit der Methode instances.insert eine Liste der gültigen Bereiche im Abschnitt Autorisierung aufgerufen.

Zugriffsbereiche haben keine Auswirkungen, wenn Sie die zugehörige API für das Projekt, zu dem das Dienstkonto gehört, nicht aktiviert haben. Wenn Sie zum Beispiel einer VM-Instanz einen Zugriffsbereich für Cloud Storage zuweisen, kann die Instanz die Cloud Storage API nur dann aufrufen, wenn die Cloud Storage API im Projekt aktiviert ist.

Standardbereiche

Wenn Sie eine neue Compute Engine-Instanz erstellen, wird diese automatisch mit den folgenden Zugriffsbereichen konfiguriert:

  • Lesezugriff auf Cloud Storage:
    https://www.googleapis.com/auth/devstorage.read_only
  • Schreibzugriff, um Compute Engine-Logs zu schreiben:
    https://www.googleapis.com/auth/logging.write
  • Schreibzugriff, um Messdaten über Ihre Google Cloud-Projekte zu veröffentlichen:
    https://www.googleapis.com/auth/monitoring.write
  • Lesezugriff auf die für Google Cloud Endpoints(Alpha) erforderlichen Service Management-Features:
    https://www.googleapis.com/auth/service.management.readonly
  • Lese-/Schreibzugriff auf die für Google Cloud Endpoints(Alpha) erforderlichen Service Control-Features:
    https://www.googleapis.com/auth/servicecontrol
  • Schreibzugriff auf Cloud Trace ermöglicht einer Anwendung, die auf einer VM ausgeführt wird, Trace-Daten in ein Projekt zu schreiben.
    https://www.googleapis.com/auth/trace.append

Best Practices für Bereiche

Es stehen viele Zugriffsbereiche zur Auswahl. Als Best Practice wird jedoch empfohlen, den Zugriffsbereich cloud-platform festzulegen (für Google Cloud-Dienste ein OAuth-Bereich) und dann den Zugriff des Dienstkontos zu steuern, indem Sie ihm IAM-Rollen zuweisen.

https://www.googleapis.com/auth/cloud-platform

Beispiele für Bereiche

Folgen Sie den Best Practices für Bereiche, wenn Sie den Zugriffsbereich cloud-platform für eine Instanz aktiviert und dann folgende vordefinierte IAM-Rollen zugewiesen haben:

  • roles/compute.instanceAdmin.v1
  • roles/storage.objectViewer
  • roles/compute.networkAdmin

Das Dienstkonto verfügt dann nur über die Berechtigungen, die in diesen drei Rollen enthalten sind. Anwendungen, die die Identität dieses Dienstkontos übernehmen, können trotz des Google Cloud-Zugriffsbereichs keine Aktionen außerhalb dieser Rollen ausführen.

Wenn Sie dagegen der Instanz einen eingeschränkteren Bereich, z. B. den schreibgeschützten Bereich "Cloud Storage" (https://www.googleapis.com/auth/devstorage.read_only), und dem Dienstkonto die Administratorrolle roles/storage.objectAdmin zuweisen, dann können mit Anfragen von der gcloud CLI und den Clientbibliotheken standardmäßig keine Cloud Storage-Objekte aus dieser Instanz verwaltet werden, obwohl Sie dem Dienstkonto die roles/storage.ObjectAdmin-Rolle zugewiesen haben. Dies liegt daran, dass die Instanz im Lesebereich von Cloud Storage nicht zum Bearbeiten von Cloud Storage-Daten autorisiert ist.

Beispiele für Zugriffsbereiche:

  • https://www.googleapis.com/auth/cloud-platform Sie können Ihre Daten in allen Google Cloud-Diensten im angegebenen Google Cloud-Projekt aufrufen und verwalten.
  • https://www.googleapis.com/auth/compute: Uneingeschränkter Zugriff auf Compute Engine-Methoden
  • https://www.googleapis.com/auth/compute.readonly: Lesezugriff auf Compute Engine-Methoden
  • https://www.googleapis.com/auth/devstorage.read_only: Lesezugriff auf Cloud Storage
  • https://www.googleapis.com/auth/logging.write. Schreibzugriff auf die Compute Engine-Logs

Nächste Schritte