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 Sie die Identität eines Dienstkontos übernehmen, 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 das Attribut impersonate-service-account fest, wenn Sie einen Befehl der Google Cloud CLI ausführen. Wenn Sie einen Befehl der gcloud CLI 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 auch das Flag --impersonate-service-account verwenden, wenn Sie die Datei mit den Standardanmeldedaten für Anwendungen einrichten. Mit dieser Konfiguration können Clientbibliotheken, die die Identitätsübernahme unterstützen, automatisch die Identität des Dienstkontos übernehmen.

  • Erstellen Sie kurzlebige Anmeldedaten mithilfe der Service Account Credentials API und verwenden Sie diese Anmeldedaten dann, um eine API-Anfrage zu authentifizieren.

    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 Konfigurationsdatei für Anmeldedaten, um eine externe Anwendung zu konfigurieren, um die Identität eines Dienstkontos zu übernehmen. Diese Option ist nur für Anwendungen verfügbar, die die Workload Identity-Föderation verwenden.

    Wenn eine Anwendung über eine Konfigurationsdatei für Anmeldedaten auf Google Cloud zugreift, nutzt sie zuerst ihre umgebungsspezifischen Anmeldedaten, um kurzlebige Anmeldedaten für ein bestimmtes Dienstkonto abzurufen. Anschließend werden diese kurzlebigen Anmeldedaten zur Authentifizierung bei Google Cloud verwendet.

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 angehängtes Dienstkonto zur Authentifizierung bei Google APIs. 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 zur Authentifizierung als Dienstkonto. 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

Zum Übernehmen der Identität eines Dienstkontos 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:

  • Nutzern vorübergehend erweiterten Zugriff gewähren
  • Testen, ob eine bestimmte Gruppe von Berechtigungen für eine Aufgabe ausreicht
  • Lokal Anwendungen entwickeln, die nur als Dienstkonto ausgeführt werden können
  • Externe Anwendungen authentifizieren

Temporären erweiterten Zugriff gewähren

In einigen Fällen kann es sinnvoll sein, einem Nutzer vorübergehend Zugriff auf bestimmte Ressourcen zu 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 erteilen sie ihnen entweder die Berechtigung, die Identität des Dienstkontos zu übernehmen, oder sie verwenden einen Token-Broker, um kurzlebige Anmeldedaten für das Dienstkonto auszustellen.

Weitere Informationen zu Methoden, mit denen Sie Nutzern vorübergehend temporären Zugriff gewähren können, finden Sie unter Übersicht über den vorübergehend erhöhten Zugriff.

Berechtigungen testen

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

Sie können die Identität von Dienstkonten übernehmen, um bestimmte Berechtigungen zu 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 eigene 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

Bei der lokalen Entwicklung von Anwendungen können Sie sich normalerweise mit Ihren Nutzeranmeldedaten 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, die eine authentifizierte Identität für Ihre Anwendung bietet. Anschließend können Sie eine Konfigurationsdatei für Anmeldedaten verwenden, um Ihre Anwendung so zu konfigurieren, dass sie die Identität eines Dienstkontos übernehmen kann.

Es ist auch möglich, externe Anwendungen mit Dienstkontoschlüsseln zu authentifizieren. Wir raten jedoch dringend davon ab. Dienstkontoschlüssel stellen ein zusätzliches Sicherheitsrisiko dar und sollten nach Möglichkeit vermieden werden.

Nächste Schritte