Einführung in die Dienstidentität

Auf dieser Seite werden die beiden Cloud Run-Identitäten beschrieben. Außerdem erfahren Sie, wie die Cloud-Clientbibliotheken die Dienstidentität verwenden, um Google Cloud APIs aufzurufen. Beispiele für Google Cloud-Produkte mit Cloud-Clientbibliotheken sind Cloud Storage, Firestore, Cloud SQL, Pub/Sub und Cloud Tasks. Diese Seite richtet sich an Administratoren, Bediener oder Entwickler, die Organisationsrichtlinien und den Nutzerzugriff verwalten, oder alle, die mehr über solche Themen erfahren möchten.

Cloud Run-Identitäten

Zur Verwendung von Cloud Run benötigt Google Cloud für den Cloud Run-Nutzer und die Cloud Run-Instanz jeweils eine Identität.

  • Die Identität des Cloud Run-Nutzers wird als Cloud Run-Bereitstellerkonto bezeichnet. Wenn Sie eine Version oder einen Job verwalten, verwenden Sie diese Identität, um Anfragen an die Cloud Run Admin API zu stellen.
  • Die Identität der Cloud Run-Instanz wird als Cloud Run-Dienstidentität bezeichnet. Wenn der Cloud Run Code, den Sie geschrieben haben, mit Cloud-Clientbibliotheken interagiert oder einen anderen Cloud Run-Dienst für die Dienst-zu-Dienst-Kommunikation aufruft, verwenden Sie diese Identität für Anfragen von Cloud Run an Google Cloud APIs oder andere Cloud Run-Diensten.

Damit Sie auf die Google Cloud APIs zugreifen und Anfragen an diese stellen oder Kommunikationen zwischen den Diensten ermöglichen können, muss jede Identität die entsprechenden Berechtigungen im Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) haben.

Cloud Run Admin API mit dem Bereitstellerkonto aufrufen

Sie können die Cloud Run Admin API über Cloud Run mit dem Cloud Run-Bereitstellerkonto aufrufen. Das Bereitstellerkonto kann entweder ein Nutzerkonto oder Dienstkonto sein und stellt das Konto dar, das in der Google Cloud-Umgebung angemeldet wurde.

Wenn das Bereitstellerkonto Cloud Run verwendet, prüft IAM, ob das Bereitstellerkonto die erforderlichen Berechtigungen zum Ausführen des Cloud Run-Vorgangs hat. Das folgende Diagramm zeigt, wie ein Nutzerkonto die Cloud Run Admin API aufruft, um eine neue Version aus der Google Cloud Console bereitzustellen:

Rufen Sie die Cloud Run Admin API über die Google Cloud Console auf.
Abbildung 1. Ein Nutzer stellt über die Google Cloud Console eine neue Version bereit, indem er eine Anfrage mit einem Zugriffstoken an die Cloud Run Admin API sendet. IAM verwendet dieses Zugriffstoken zur Verifizierung, dass das Nutzerkonto für den Zugriff auf die Cloud Run Admin API authentifiziert ist, bevor der Vorgang beginnt.

Google Cloud APIs mit der Dienstidentität aufrufen

Wenn eine Cloud Run-Instanz mit anderen IAM-authentifizierten Cloud Run-Diensten interagiert oder Cloud-Clientbibliotheken durch Anwendungscode oder integrierte Funktionen wie Cloud Run-Integrationen oder Cloud Storage-Volume-Bereitstellungen aufruft, nutzt die Google Cloud-Umgebung Standardanmeldedaten für Anwendungen, um automatisch zu erkennen, ob die Cloud Run-Dienstidentität dafür authentifiziert ist, den API-Vorgang auszuführen. Cloud Run-Dienstidentität ist ein Dienstkonto, das als Identität der Cloud Run-Instanz zugewiesen wurde, als Sie eine Version bereitstellten oder einen Auftrag ausführten.

Ein Dienstkonto, das als Bereitstellerkonto verwendet wird, wird nur als Dienstidentität verwendet, wenn Sie dasselbe Dienstkonto in Ihrer Cloud Run-Konfiguration konfigurieren.

Im weiteren Verlauf dieses Leitfadens wird beschrieben, wie ein Cloud Run-Dienst oder -Job die Dienstidentität verwendet, um Google-Dienste und APIs aufzurufen und auf sie zuzugreifen. Weitere Informationen zur Konfiguration der Dienstidentität, siehe Konfigurationsseiten für Dienstidentität für Dienste und Jobs.

Arten von Dienstkonten für die Dienstidentität

Wenn Ihre Cloud Run-Instanz Aufrufe an Google Cloud APIs sendet, um Abläufe durchzuführen, verwendet Cloud Run automatisch ein Dienstkonto als Dienstidentität. Die zwei Arten von Dienstkonten können so als Dienstidentität verwendet werden:

  • Vom Nutzer verwaltetes Dienstkonto (empfohlen): Sie erstellen dieses Dienstkonto manuell und legen den Mindestsatz an Berechtigungen fest, die vom Dienstkonto für den Zugriff auf bestimmte Google Cloud-Ressourcen benötigt werden. Das vom Nutzer verwaltete Dienstkonto hat das Format SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com.
  • Compute Engine-Standarddienstkonto: Cloud Run liefert automatisch das Compute Engine-Standarddienstkonto als Standarddienstidentität. Das Compute Engine-Standarddienstkonto folgt dem Format PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Standarddienstkonto beim Konfigurieren der Dienstidentität vermeiden

Standardmäßig wird das Compute Engine-Standarddienstkonto automatisch erstellt. Wenn Sie kein Dienstkonto angeben, wenn der Cloud Run-Dienst oder -Job erstellt wird, verwendet Cloud Run dieses Dienstkonto.

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.

Funktionsweise von Service Identity

Wenn Ihr Code Cloud-Clientbibliotheken aufruft oder Anfragen an sie sendet, geschieht Folgendes:

  1. Die Clientbibliotheken erkennen, dass eine Anfrage an eine Google Cloud API oder Cloud-Clientbibliotheken gesendet wird und fordern ein OAuth 2.0-Zugriffstoken für die Dienstidentität vom Instanz-Metadatenserver an.
  2. Der Instanz-Metadatenserver stellt ein IAM-Zugriffstoken für das Dienstkonto, das als Dienstidentität konfiguriert ist bereit.
  3. Die Anfrage an die Google Cloud API wird mit einem OAuth 2.0-Zugriffstoken gesendet.
  4. IAM überprüft die Dienstidentität, auf die im Zugriffstoken für die erforderlichen Berechtigungen verwiesen wird und prüft Richtlinienbindungen, bevor es den Aufruf an den API-Endpunkt weiterleitet.
  5. Der Vorgang wird von der Google Cloud API ausgeführt.
Google Cloud API über Cloud Run aufrufen.
Abbildung 1. Cloud Run generiert ein Zugriffstoken vom Metadatenserver, und IAM verwendet dieses Zugriffstoken, um zu prüfen, ob die zugewiesene Cloud Run-Dienstidentität für den Zugriff auf die Google Cloud APIs authentifiziert ist.

Zugriffstoken für die Cloud Run-Anfrage zum Aufrufen von Google Cloud APIs generieren

Wenn Ihr Cloud Run-Code Cloud-Clientbibliotheken verwendet, konfigurieren eine Dienstidentität in Cloud Run durch Zuweisen eines Dienstkontos unter Bereitstellung oder Ausführung. Dadurch erhält die Bibliothek automatisch ein Zugriffstoken, um die Anfrage Ihres Codes zu authentifizieren. Wenn Ihr Cloud Run-Code mit anderen authentifizierten Cloud Run-Diensten kommuniziert, müssen Sie Ihren Anfragen das Zugriffstoken hinzufügen.

Um ein Dienstkonto als Dienstidentität zuzuweisen, lesen Sie die folgenden Leitfäden:

Wenn Sie jedoch Ihren eigenen benutzerdefinierten Code verwenden oder Anfragen programmatisch stellen müssen, können Sie den Metadatenserver direkt verwenden, um die im nächsten Abschnitt beschriebenen Identitäts- und Zugriffstoken manuell abzurufen. Hinweis: Sie können diesen Server nicht direkt von Ihrem lokalen Computer aus abfragen, da der Metadatenserver nur für Arbeitslasten verfügbar ist, die in Google Cloud ausgeführt werden.

ID- und Zugriffstokens mit dem Metadatenserver abrufen

Sie können die folgenden zwei Tokentypen mit dem Metadatenserver abrufen:

Um ein Token abzurufen, folgen Sie der Anleitung auf dem jeweiligen Tab für das Token, das Sie verwenden:

Zugriffstokens

Wenn Sie beispielsweise ein Pub/Sub-Thema erstellen möchten, verwenden Sie die Methode projects.topics.create.

  1. Verwenden Sie den Compute-Metadatenserver, um ein Zugriffstoken abzurufen:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
    --header "Metadata-Flavor: Google"

    Dieser Endpunkt gibt eine JSON-Antwort mit einem access_token-Attribut zurück.

  2. In Ihrer HTTP-Protokollanfrage muss die Anfrage mit einem Zugriffstoken im Header Authorization:

    PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
Authorization: Bearer ACCESS_TOKEN

    Wobei:

    • PROJECT_ID ist die Projekt-ID.
    • TOPIC_ID ist Ihre Themen-ID.
    • ACCESS_TOKEN ist das abgerufene Zugriffstoken aus dem vorherigen Schritt.

    Lösung:

    {
    "name": "projects/PROJECT_ID/topics/TOPIC_ID"
}

ID-Tokens

Verwenden Sie den Compute Metadata Server, um ein Identitätstoken für eine bestimmte Zielgruppe abzurufen:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
    --header "Metadata-Flavor: Google"

Dabei ist AUDIENCE die angeforderte JWT-Zielgruppe.

Bei Cloud Run-Diensten sollte die Zielgruppe entweder die URL des Dienstes sein, den Sie aufrufen, oder eine benutzerdefinierte Zielgruppe, z. B. eine benutzerdefinierte Domain, die für den Dienst konfiguriert ist.

https://service.domain.com

Für andere Ressourcen ist dies wahrscheinlich die OAuth-Client-ID einer IAP-geschützten Ressource:

1234567890.apps.googleusercontent.com

Weitere Informationen