Arten von Dienstkonten

Dienstkonten lassen sich in die folgenden Kategorien unterteilen:

• Nutzerverwaltete Dienstkonten, die Sie selbst erstellen und verwalten
• Dienst-Agents, die von erstellt und verwaltet werden Google Cloud

Auf dieser Seite wird beschrieben, wie die einzelnen Arten von Dienstkonten erstellt und verwendet werden.

Nutzerverwaltete Dienstkonten

Nutzerverwaltete Dienstkonten sind Dienstkonten, die Sie in Ihren Projekten erstellen. Sie können diese Dienstkonten nach Belieben aktualisieren, deaktivieren, aktivieren und löschen. Sie können auch den Zugriff anderer Hauptkonten auf diese Dienstkonten verwalten.

Sie können in Ihrem Projekt nutzerverwaltete Dienstkonten mit der IAM API, der Google Cloud Console oder der Google Cloud CLI erstellen.

Die Anzahl der Dienstkonten, die Sie in jedem Projekt haben können, hängt von Ihrem Projekt ab. Wenn Sie das Kontingent für ein Projekt aufrufen möchten, sehen Sie sich die Kontingente Ihres Projekts in der Google Cloud Console an und suchen Sie nach Anzahl der Dienstkonten.

Wenn Sie in Ihrem Projekt ein nutzerverwaltetes Dienstkonto erstellen, müssen Sie einen Namen für das Dienstkonto festlegen. Dieser Name erscheint in der E-Mail-Adresse, die das Dienstkonto identifiziert. Diese hat folgendes Format:

[e-mail]

Informationen zum Erstellen eines Dienstkontos finden Sie unter Dienstkonten erstellen.

Standarddienstkonten

Standarddienstkonten sind nutzerverwaltete Dienstkonten, die automatisch erstellt werden, wenn Sie bestimmte Google Cloud Dienste aktivieren oder verwenden. Mit diesen Dienstkonten kann der Dienst Jobs bereitstellen, die auf andere Google Cloud Ressourcen zugreifen. Sie sind dafür verantwortlich, Standarddienstkonten nach ihrer Erstellung zu verwalten.

Wenn Ihre Anwendung in einer Google Cloud Umgebung mit einem Standarddienstkonto ausgeführt wird, kann sie mit den Anmeldedaten für das Standarddienstkonto Google Cloud APIs aufrufen. Alternativ können Sie Ihr eigenes nutzerverwaltetes Dienstkonto erstellen und es zur Authentifizierung verwenden. Weitere Informationen finden Sie unter Standardanmeldedaten für Anwendungen einrichten.

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 Standard Dienstkonten zugeteilt werden sollen, und dann diese Rollen 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 von der Änderung zu sehen, und weisen Sie die entsprechenden Rollen zu und widerrufen Sie sie.

Hinweis: Wenn Sie eine Rollenbindung ersetzen, die seit mehr als 90 Tagen besteht, können Sie mithilfe der Rollenempfehlungen feststellen, welche Rollen stattdessen zugewiesen werden sollen. Sie können auch den Policy Simulator verwenden, um sicherzustellen, dass sich eine Änderung der Rolle nicht auf den Zugriff des Dienstkontos auswirkt.

In der folgenden Tabelle sind die Dienste aufgeführt, die Standarddienstkonten erstellen:

Dienst	Name des Dienstkontos	E-Mail-Adresse
App Engine und alle Google Cloud Dienste, die App Engine nutzen	App Engine-Standarddienstkonto	[e-mail]
Compute Engine und alle Google Cloud Dienste, die Compute Engine nutzen	Standardmäßiges Compute Engine-Dienstkonto	[e-mail]

**Hinweis**: Sowohl das Erstellungsdatum als auch das E-Mail-Adressformat von Standarddienstkonten können geändert werden.

Kundenservicemitarbeiter

Einige Google Cloud Dienste benötigen Zugriff auf Ihre Ressourcen, damit sie Aufgaben für Sie ausführen können. Wenn Sie beispielsweise einen Container mit Cloud Run ausführen, benötigt der Dienst Zugriff auf alle Pub/Sub-Themen, die den Container auslösen können.

Damit dies möglich ist, Google Cloud erstellt und verwaltet Dienstkonten für viele Google Cloud Dienste. Diese Dienstkonten werden als Dienst-Agents bezeichnet. Unter Umständen sehen Sie Dienst-Agents in der Zulassungsrichtlinie Ihres Projekts, in Audit Logs oder auf der IAM-Seite in der Google Cloud Console. Eine vollständige Liste der Dienst-Agents finden Sie unter Dienst-Agents.

Dienst-Agents werden nicht in Ihren Projekten erstellt. Daher werden sie bei der Anzeige der Dienstkonten Ihrer Projekte nicht angezeigt. Sie können nicht direkt darauf zugreifen.

Standardmäßig werden Dienst-Agents auf der Seite IAM in der Google Cloud Console nicht aufgeführt, auch wenn ihnen in Ihrem Projekt eine Rolle zugewiesen wurde. Klicken Sie auf das Kästchen Von Google bereitgestellte Rollenzuweisungen einschließen, um Rollenzuweisungen für Dienst-Agents aufzurufen.

**Hinweis**: Sowohl das Erstellungsdatum als auch das E-Mail-Adressformat von Dienst-Agents können geändert werden.

Google Cloud bietet die folgenden Arten von Dienst-Agents:

• Dienstspezifische Dienst-Agents
• Google APIs-Dienst-Agent
• Rollenmanager für Dienst-Agents

Dienstspezifische Dienst-Agents

Die meisten Dienst-Agents sind dienstspezifisch – sie agieren im Namen von einzelnen Diensten. In vielen Fällen sind diese Dienst-Agents erforderlich, damit Dienste ordnungsgemäß funktionieren. Dienst-Agents ermöglichen es Cloud Logging-Senken beispielsweise, Logs in Cloud Storage-Buckets zu schreiben.

Jeder Dienst-Agent ist mit einer Ressource verknüpft. Diese Ressource ist normalerweise ein Projekt, ein Ordner oder eine Organisation. Es kann jedoch auch eine dienstspezifische Ressource sein, z. B. eine Cloud SQL-Instanz. Diese Ressource definiert den Bereich der Aktionen des Dienst-Agents. Wenn ein Dienst-Agent beispielsweise mit einem Projekt verknüpft ist, wird er im Namen eines Dienstes für das Projekt und seine untergeordneten Ressourcen agieren.

Ermitteln Sie anhand der E-Mail-Adresse, welchem Ressourcentyp ein Dienst-Agent zugeordnet ist:

• Wenn der Dienst-Agent mit einem Projekt, Ordner oder einer Organisation verknüpft ist, enthält die E-Mail-Adresse die numerische ID für dieses Projekt, diesen Ordner oder diese Organisation.
• Wenn der Dienst-Agent einer dienstspezifischen Ressource zugeordnet ist, enthält die E-Mail-Adresse eine numerische Projekt-ID und eine eindeutige Kennung. Die numerische Projekt-ID gibt an, welchem Projekt die Ressource gehört, mit der der Dienst-Agent verknüpft ist. Die eindeutige Kennung unterscheidet den Dienst-Agent von anderen ähnlichen Dienst-Agents im selben Projekt.

Google APIs-Dienst-Agent

Die Zulassungsrichtlinie Ihres Projekts verweist wahrscheinlich auf ein Dienstkonto mit dem Namen des Google APIs-Dienst-Agents mit einer E-Mail-Adresse im folgenden Format: [e-mail].

Dieses Dienstkonto führt in Ihrem Namen interne Google Cloud Vorgänge aus. Es erhält automatisch die Rolle "Bearbeiter" (roles/editor) für das Projekt.

Warnung: Widerrufen Sie die Rollen, die dem Google APIs-Dienst-Agent zugewiesen sind, nur, wenn dies durch eine Rollenempfehlung vorgeschlagen wird. Wenn Sie diese Rollen auf eine Weise widerrufen, die nicht durch eine Rollenempfehlung vorgeschlagen wird, funktionieren einige Google Cloud Dienste nicht mehr.

Rollenmanager für Dienst-Agents

Ihre Audit-Logs für IAM beziehen sich möglicherweise auf das Dienst konto [e-mail].

Dieses Dienstkonto verwaltet die Rollen, die anderen Dienst-Agents zugewiesen sind. Es ist nur in Audit-Logs sichtbar.

Wenn Sie beispielsweise eine neue API verwenden, kann automatisch ein neuer Dienst-Agent erstellt und ihm Rollen für Ihr Projekt zugewiesen werden. Google Cloud Durch das Zuweisen dieser Rollen wird ein Audit-Logeintrag generiert, aus dem hervorgeht, dass [e-mail] die Zulassungsrichtlinie für das Projekt festgelegt hat.

Dienst-Agent erstellen

Die genaue Zeit, zu der ein Dienst-Agent erstellt wird, hängt von der Art der Ressource ab, der er zugeordnet ist.

Dienst-Agents, die einer dienstspezifischen Ressource zugeordnet sind, werden beim Erstellen der Ressource erstellt. Weitere Informationen zum Identifizieren und Konfigurieren dieser Dienst-Agents finden Sie in der Dokumentation zur zugehörigen Ressource.

Dienst-Agents, die Projekten, Ordnern und Organisationen zugeordnet sind, werden nach Bedarf erstellt, in der Regel, wenn Sie einen Dienst zum ersten Mal verwenden. Bei Bedarf können Sie auch bitten, Dienst-Agents für einen Dienst zu erstellen, Google Cloud bevor Sie den Dienst verwenden. Weitere Informationen finden Sie unter Rollen erstellen und ihnen Dienst-Agents zuweisen.

Hinweis: Wenn mehrere Dienst-Agents gleichzeitig erstellt werden, kann ein Fehler aufgrund einer gleichzeitigen Richtlinienänderung auftreten, während der Dienst-Agent Manager versucht, den Dienst-Agents Rollen zuzuweisen. Es ist keine Aktion erforderlich, um diesen Fehler zu beheben. Der Dienst-Agent-Manager wiederholt die Aktion automatisch, bis alle Dienst-Agents die richtigen Rollen haben.

IAM-Rollen für Dienst-Agents

Für einige Aktionen in Google Cloud müssen Dienst-Agents in Ihrem Namen Ressourcen erstellen und darauf zugreifen. Wenn Sie beispielsweise einen Managed Service for Apache Spark-Cluster erstellen, benötigt der Managed Service for Apache Spark-Dienst-Agent die Berechtigung, Compute Engine-Instanzen in Ihrem Projekt zu erstellen, um den Cluster zu erstellen.

Dienstzugriff-Agents benötigen bestimmte IAM-Rollen, um diesen Zugriff zu erhalten. Viele Dienst-Agents auf Projektebene erhalten automatisch die Rollen, die sie benötigen. Die Namen dieser automatisch zugewiesenen Rollen enden in der Regel mit serviceAgent oder ServiceAgent. Anderen Dienst-Agents müssen Sie diese Rollen zuweisen, damit der Dienst ordnungsgemäß funktioniert. Informationen dazu, welchen Dienst-Agents automatisch Rollen zugewiesen werden, finden Sie in der Referenz zum Dienst-Agent.

Wenn Sie bestimmten Hauptkontogruppen, zu denen Dienst-Agents gehören, bestimmte Berechtigungen verweigern müssen, z. B. der Hauptkontogruppe principalSet://goog/public:all, empfehlen wir, Ihre Dienst- Agents als Ausnahmen in der Verweigerungsregel hinzuzufügen. So können Sie sicherstellen, dass Ihre Dienste weiterhin ordnungsgemäß funktionieren. Verwenden Sie beim Hinzufügen von Dienst-Agents als Ausnahmen die Hauptkontogruppe des Dienst-Agents des Projekts, Ordners oder der Organisation.

Warnung: Widerrufen Sie die Rollen, die Dienst-Agents zugewiesen sind, nur, wenn dies durch eine Rollenempfehlung vorgeschlagen wird. Wenn Sie diese Rollen auf eine Weise widerrufen, die nicht durch eine Rollenempfehlung vorgeschlagen wird, funktionieren einige Google Cloud Dienste nicht mehr. Damit diese Rollen nicht widerrufen werden, können Sie eine benutzerdefinierte Organisationsrichtlinie implementieren, die verhindert, dass Nutzer Dienst-Agent-Rollen widerrufen.

Wenn Sie bitten, Google Cloud Dienst-Agents zu erstellen, bevor Sie einen Dienst verwenden, müssen Sie den Dienst-Agents die Rollen zuweisen, die ihnen normalerweise zugewiesen werden automatisch. Dies liegt daran, dass Dienst-Agents, die auf Anfrage eines Nutzers erstellt werden, nicht automatisch Rollen zugewiesen werden. Wenn Sie den Dienst-Agents diese Rollen nicht zuweisen, funktionieren einige Dienste möglicherweise nicht ordnungsgemäß. Informationen zum Zuweisen dieser Rollen für Dienst-Agents finden Sie unter Rollen erstellen und zuweisen.

Primäre Dienst-Agents

In der Referenz zum Dienst-Agent werden einige Dienst-Agents als primäre Dienst-Agents identifiziert. Primäre Dienst-Agents sind Dienst Agents, deren E-Mail-Adresse zurückgegeben wird, wenn Sie für einen Dienst die Erstellung des Dienst-Agents auslösen.

Audit-Logs für Dienst-Agents

Manchmal führt ein Dienst-Agent eine Aktion im Namen des Hauptkontos aus, wenn dieses einen Vorgang initiiert. Wenn Sie jedoch Audit-Logs für einen Dienst-Agent prüfen, kann es schwierig sein zu erkennen, in wessen Namen der Dienst-Agent gehandelt hat und warum.

Damit Sie den Kontext für die Aktionen eines Dienst-Agents besser nachvollziehen können, fügen einige Dienst-Agents zusätzliche Details in ihre Audit-Logs ein, z. B. den Job, mit der die Aktion verknüpft ist, und das Hauptkonto, das den Job erstellt hat.

Die folgenden Dienst-Agents fügen ihren Audit-Logs diese zusätzlichen Details hinzu:

• BigQuery-Verbindungsdienst-Agent
• BigQuery-Verbindungsdelegierungsdienst-Agent

Diese zusätzlichen Details befinden sich im serviceDelegationHistory Feld des Audit-Logs, das im authenticationInfo Feld verschachtelt ist. Dieses Feld enthält die folgenden Informationen:

• Das ursprüngliche Hauptkonto, das den Job erstellt hat
• Der Dienst-Agent, der die Aktion ausgeführt hat
• Der Dienst, zu dem der Dienst-Agent gehört
• Die Job-ID

Angenommen, [e-mail] erstellt einen Job mit der BigQuery Connection API. Für diesen Job muss einer der Dienst-Agents der BigQuery Connection API eine Aktion ausführen. In diesem Fall enthält das Audit-Log für die Aktion des Dienst-Agents ein serviceDelegationHistory Feld, das dem folgenden ähnelt:

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalEmail": "[e-mail]",
      "serviceDelegationHistory": {
        "originalPrincipal": "user:[e-mail]",
        "serviceMetadata": [
          {
            "principalSubject": "serviceAccount:[e-mail]",
            "serviceDomain": "bigquery.googleapis.com",
          }
        ]
      }
    }
  }
}

Nächste Schritte

• Erfahren Sie, wie Sie Dienstkonten erstellen und verwalten.
• Mehr über das Erstellen und Verwalten von Dienstkontoschlüsseln
• Best Practices für die Arbeit mit Dienstkonten
• Best Practices für die Verwaltung von Dienstkontoschlüsseln

Überzeugen Sie sich selbst

Wenn Sie noch kein Nutzer von Google Cloudsind, erstellen Sie ein Konto, um die Leistung unserer Produkte 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.

Jetzt kostenlos starten