Identitätsübernahme des Dienstkontos

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. Durch die Übernahme der Identität eines Dienstkontos kann ein authentifiziertes Hauptkonto auf alles zugreifen, worauf 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 Cloudausgeführt werden.

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

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 dann mit diesen Anmeldedaten aus.

    Sie können das Flag --impersonate-service-account auch verwenden, wenn Sie Ihre ADC-Datei (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 mit 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 so zu konfigurieren, dass sie die Identität eines Dienstkontos annimmt. Diese Option ist nur für Anwendungen verfügbar, die Workload Identity-Föderation verwenden.

    Wenn eine Anwendung eine Anmeldedatenkonfigurationsdatei verwendet, um aufGoogle Cloudzuzugreifen, verwendet sie zuerst ihre umgebungsspezifischen Anmeldedaten, um kurzlebige Anmeldedaten für ein bestimmtes Dienstkonto abzurufen. Anschließend werden diese kurzlebigen Anmeldedaten zur Authentifizierung bei Google Cloudverwendet.

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 -Konsole verwenden, authentifizieren Sie sich immer mit Ihren Nutzeranmeldedaten. Sie können die Identität eines Dienstkontos nicht übernehmen, um auf Ressourcen in derGoogle Cloud -Konsole zuzugreifen.

Authentifizierung ohne Identitätsübernahme

Es gibt verschiedene 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, 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 dazu, wie sich Workloads bei Google Cloudauthentifizieren, finden Sie unter Identitäten für Workloads.

  • 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

Um die Identität eines Dienstkontos zu übernehmen, 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 erweiterten Zugriff gewähren
  • Testen, ob ein bestimmter Satz von Berechtigungen für eine Aufgabe ausreicht
  • Anwendungen lokal entwickeln, die nur als Dienstkonto ausgeführt werden können
  • Externe Anwendungen authentifizieren

Temporären erweiterten 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 lassen Sie Nutzer die Identität des Dienstkontos übernehmen, indem Sie ihnen die Berechtigung dazu erteilen oder einen Tokenbroker verwenden, um kurzlebige Anmeldedaten für das Dienstkonto auszugeben.

Weitere Informationen zu Methoden zum Gewähren eines temporären erweiterten Zugriffs finden Sie unter Übersicht über temporären erweiterten Zugriff.

Berechtigungen testen

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

Sie können die Identitätsübernahme von Dienstkonten verwenden, um einen bestimmten Satz von 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 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 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 vonGoogle Cloud laufen, bei Google Cloudauthentifizieren. 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 bereitstellt. Anschließend können Sie eine Konfigurationsdatei für Anmeldedaten verwenden, um Ihre Anwendung für den Identitätswechsel eines Dienstkontos zu konfigurieren.

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

Nächste Schritte