Identitätsübertragung für ein Dienstkonto

Wenn sich ein authentifiziertes Hauptkonto, z. B. ein Nutzer oder ein anderes Dienstkonto, als ein Dienstkonto authentifiziert, um die Berechtigungen des Dienstkontos zu erhalten, wird dies als Identitätsübernahme des Dienstkontos bezeichnet. Wenn die Identität eines Dienstkontos übernommen wird, kann ein authentifiziertes Hauptkonto auf alles zugreifen, auf das das Dienstkonto zugreifen kann. Nur authentifizierte Hauptkonten mit den entsprechenden Berechtigungen können die Identität von Dienstkonten übernehmen.

Die Identitätsübernahme ist nützlich, wenn Sie die Berechtigungen eines Nutzers ändern möchten, ohne Ihre IAM-Richtlinien (Identity and Access Management) zu ändern. So können Sie beispielsweise die Identitätsübernahme verwenden, um einem Nutzer vorübergehend erweiterten Zugriff zu gewähren oder um zu testen, ob ein bestimmter Satz von Berechtigungen für eine Aufgabe ausreichend ist. Sie können die Identitätsübernahme auch verwenden, um Anwendungen lokal zu entwickeln, die nur als Dienstkonto ausgeführt werden können, oder um Anwendungen zu authentifizieren, die außerhalb von Google Cloud ausgeführt werden.

Die Identitätsübernahme eines Google Cloud-Dienstkontos ähnelt den Methoden der Amazon Web Services (AWS) Security Token Service API wie AssumeRole.

Funktionsweise der Identitätsübernahme von Dienstkonten

Die Identitätsübernahme für ein Dienstkonto umfasst immer zwei Identitäten: ein authentifiziertes Hauptkonto und das Dienstkonto, dessen Identität das Hauptkonto annimmt. Um die Identität des Dienstkontos zu übernehmen, erhält das authentifizierte Hauptkonto ein Token für das Dienstkonto und verwendet dann dieses Token, um sich als das Dienstkonto zu authentifizieren.

Es gibt mehrere Möglichkeiten, die Identität eines Dienstkontos zu übernehmen:

  • Legen Sie das Flag --impersonate-service-account oder die Eigenschaft impersonate-service-account fest, wenn Sie einen Google Cloud CLI-Befehl ausführen. Wenn Sie einen gcloud CLI-Befehl mit dieser Einstellung ausführen, erstellt die gcloud CLI kurzlebige Anmeldedaten für das Dienstkonto und führt den Befehl mit diesen Anmeldedaten aus.

    Sie können das Flag --impersonate-service-account auch beim Einrichten der Datei mit Standardanmeldedaten für Anwendungen verwenden. Mit dieser Konfiguration können Clientbibliotheken, die die Identitätsübernahme unterstützen, automatisch die Identität des Dienstkontos übernehmen.

  • Erstellen Sie kurzlebige Anmeldedaten mit der Service Account Credentials API und authentifizieren Sie dann eine API-Anfrage mit diesen Anmeldedaten.

    Kurzlebige Anmeldedaten für Dienstkonten haben eine beschränkte Lebensdauer, die in der Regel bei wenigen Stunden liegt, und werden nicht automatisch aktualisiert. Sie stellen ein geringeres Risiko als langlebige Anmeldedaten wie Dienstkontoschlüssel dar.

  • Verwenden Sie eine Anmeldedatenkonfigurationsdatei, um eine externe Anwendung so zu konfigurieren, dass sie sich als Dienstkonto ausgibt. Diese Option ist nur für Anwendungen verfügbar, die die Workload Identity-Föderation verwenden.

    Wenn eine Anwendung eine Anmeldedatenkonfigurationsdatei für den Zugriff auf Google Cloud verwendet, werden zuerst die umgebungsspezifischen Anmeldedaten verwendet, um kurzlebige Anmeldedaten für ein bestimmtes Dienstkonto abzurufen. Anschließend wird mit diesen kurzlebigen Anmeldedaten die Authentifizierung bei Google Cloud durchgeführt.

Wenn ein Hauptkonto auf Ressourcen zugreift, während es die Identität eines Dienstkontos übernimmt, enthalten die meisten Audit-Logs sowohl ihre Identität als auch die Identität des Dienstkontos, dessen Identität übernommen wird. Weitere Informationen finden Sie unter Audit-Logs analysieren.

Wenn Sie die Google Cloud Console verwenden, authentifizieren Sie sich immer mit Ihren Nutzeranmeldedaten. Sie können die Identität eines Dienstkontos nicht übernehmen, um auf Ressourcen in der Google Cloud Console zuzugreifen.

Authentifizierung ohne Identitätsübernahme

Es gibt mehrere Möglichkeiten, wie sich eine Arbeitslast oder ein Nutzer als Dienstkonto authentifizieren kann, ohne die Identität des Dienstkontos zu übernehmen:

  • Eine Arbeitslast verwendet ein verknüpftes Dienstkonto, um sich bei Google APIs zu authentifizieren. In diesem Fall fungiert das angehängte Dienstkonto als Identität der Arbeitslast und ist die einzige authentifizierte Identität, die an der Anfrage beteiligt ist.

    Informationen zur Authentifizierung von Arbeitslasten bei Google Cloud finden Sie unter Identitäten für Arbeitslasten.

  • Ein Hauptkonto verwendet einen Dienstkontoschlüssel, um sich als Dienstkonto zu authentifizieren. Die Verwendung eines Dienstkontoschlüssels für die Authentifizierung als Dienstkonto umfasst nur eine authentifizierte Identität: die des Dienstkontos. Da nur eine Identität beteiligt ist, entspricht die Verwendung eines Schlüssels nicht der Identitätsübernahme des Dienstkontos.

In diesen Fällen zeichnen die Audit-Logs nur die Identität des Dienstkontos auf. Sie zeichnen keine anderen Identitäten auf, z. B. die Identitäten der Nutzer, die Code für die Arbeitslast ausgeführt haben, oder die Identitäten der Nutzer, die den Dienstkontoschlüssel zur Authentifizierung verwendet haben. Die Verwendung von Dienstkontoschlüsseln oder die Berechtigung von Entwicklern zum Ausführen von Code auf privilegierten Ressourcen, z. B. eine SSH-Sitzung zu einer VM-Instanz, kann daher zu Risiken in Bezug auf die Rechteausweitung und Nachweisbarkeit führen.

Erforderliche Berechtigungen

Wenn Sie die Identität eines Dienstkontos übernehmen möchten, benötigen Sie die Berechtigung iam.serviceAccounts.getAccessToken. Diese Berechtigung ist in Rollen wie der Rolle „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator) enthalten.

Weitere Informationen zu den für die Identitätsübertragung erforderlichen Rollen finden Sie unter Rollen für die Dienstkontoauthentifizierung.

Anwendungsfälle für die Identitätsübernahme von Dienstkonten

Die Identitätsübernahme eines Dienstkontos ist nützlich, wenn Sie Aufgaben wie die folgenden ausführen müssen:

  • Nutzer vorübergehend erhöhte Zugriffsrechte gewähren
  • Testen, ob eine bestimmte Gruppe von Berechtigungen für eine Aufgabe ausreicht
  • Anwendungen lokal entwickeln, die nur als Dienstkonto ausgeführt werden können
  • Externe Anwendungen authentifizieren

Temporären erhöhten Zugriff gewähren

In einigen Fällen möchten Sie einem Nutzer möglicherweise vorübergehend Zugriff auf bestimmte Ressourcen gewähren. Sie können beispielsweise einem anderen Nutzer zusätzlichen Zugriff gewähren, damit er einen Vorfall beheben kann, oder einer Person für einen begrenzten Zeitraum Zugriff auf vertrauliche Daten gewähren, nachdem diese eine Begründung protokolliert hat.

Die Identitätsübernahme von Dienstkonten ist eine Möglichkeit, diesen Nutzern vorübergehend Zugriff zu gewähren. Um ein Dienstkonto für einen vorübergehenden erweiterten Zugriff zu verwenden, gewähren Sie ihm zuerst die IAM-Rollen, die Sie den Nutzern vorübergehend zuweisen möchten. Anschließend können Sie Nutzern erlauben, die Identität des Dienstkontos zu übernehmen. Dazu können Sie ihnen entweder die Berechtigung dazu erteilen oder mithilfe eines Token-Brokers kurzlebige Anmeldedaten für das Dienstkonto ausstellen.

Weitere Informationen zu Methoden zum Gewähren eines temporären erweiterten Zugriffs finden Sie unter Temporärer erweiterter Zugriff.

Berechtigungen testen

In einigen Fällen möchten Sie möglicherweise prüfen, ob ein bestimmter Satz von Berechtigungen für eine Aufgabe ausreichend ist. So können Sie beispielsweise prüfen, ob ein Dienstkonto eine Anwendung weiterhin ausführen kann, wenn Sie bestimmte überflüssige Berechtigungen entfernen. Oder Sie helfen einem Nutzer bei der Fehlerbehebung bei einer Aufgabe und möchten prüfen, ob er mit seinen aktuellen IAM-Rollen einen bestimmten Befehl ausführen kann.

Mit der Identitätsübernahme für Dienstkonten können Sie einen bestimmten Satz von Berechtigungen testen. Erstellen Sie zuerst ein Dienstkonto und weisen Sie ihm eine oder mehrere IAM-Rollen mit den Berechtigungen zu, die Sie testen möchten. Übernehmen Sie dann die Identität des Dienstkontos und führen Sie die Aufgabe aus. Mit dieser Methode können Sie Berechtigungen testen, ohne Testnutzerkonten erstellen oder Ihre eigenen IAM-Berechtigungen ändern zu müssen.

Informationen zum Übernehmen der Identität von Dienstkonten finden Sie unter Identitätsübernahme des Dienstkontos verwenden.

Anwendungen lokal entwickeln

Wenn Sie Anwendungen lokal entwickeln, können Sie sich in der Regel mit Ihren Nutzer-Anmeldedaten authentifizieren. In einigen Situationen ist dies jedoch nicht möglich, z. B. wenn Sie sich bei einem Dienst authentifizieren möchten, für den ein Token mit einer benutzerdefinierten Zielgruppe erforderlich ist, das Nutzer normalerweise nicht konfigurieren können. In diesen Fällen müssen Sie sich als Dienstkonto und nicht mit Ihren Nutzeranmeldedaten authentifizieren.

In diesen Fällen empfehlen wir die Identitätsübernahme des Dienstkontos. Durch die Verwendung der Identitätsübernahme des Dienstkontos können Sie die Verwendung von Dienstkontoschlüsseln vermeiden, die ein zusätzliches Sicherheitsrisiko darstellen.

Informationen zum Übernehmen der Identität von Dienstkonten für die Entwicklung von Anwendungen finden Sie unter Identitätsübernahme des Dienstkontos.

Externe Anwendungen authentifizieren

Für den Zugriff auf Google Cloud-Ressourcen müssen sich Anwendungen, die außerhalb von Google Cloud laufen, bei Google Cloud authentifizieren. Eine Möglichkeit, diese Anwendungen zu authentifizieren, ist die Identitätsübernahme des Dienstkontos.

Damit Ihre Anwendung die Identität eines Dienstkontos übernehmen kann, müssen Sie zuerst die Workload Identity-Föderation einrichten. Diese stellt eine authentifizierte Identität für Ihre Anwendung bereit. Anschließend können Sie Ihre Anwendung mit einer Anmeldedatenkonfigurationsdatei so konfigurieren, dass sie sich als Dienstkonto ausgibt.

Es ist zwar möglich, Dienstkontoschlüssel zur Authentifizierung externer Anwendungen zu verwenden, wir raten jedoch dringend davon ab. Dienstkontoschlüssel stellen ein zusätzliches Sicherheitsrisiko dar und sollten nach Möglichkeit vermieden werden.

Nächste Schritte