Dienstidentität

Jede Cloud Run-Überarbeitung oder jeder Cloud Run-Job ist mit einem Dienstkonto verknüpft. Dieses Dienstkonto wird automatisch von den Google Cloud-Clientbibliotheken zur Authentifizierung bei Google Cloud APIs verwendet. Beispiele für Google Cloud APIs, mit denen der Code Ihres Dienstes Schnittstellen umfassen kann, sind Cloud Storage, Firestore, Cloud SQL, Pub/Sub oder Cloud Tasks.

Wenn Sie kein Dienstkonto angeben, verknüpft Cloud Run eine Überarbeitung oder einen Job mit dem Standarddienstkonto, das umfassende Berechtigungen in allen Google Cloud APIs hat. Google empfiehlt, stattdessen die Identität pro Dienst zu verwenden und selektive Berechtigungen zu erteilen.

Standarddienstkonto

Cloud Run-Überarbeitungen und -Jobs werden standardmäßig als Compute Engine-Standarddienstkonto ausgeführt. Das Compute Engine-Standarddienstkonto hat die IAM-Rolle Projektbearbeiter, die Lese- und Schreibberechtigungen für alle Ressourcen in Ihrem Google Cloud-Projekt gewährt.

Dies mag zwar praktisch sein, aber Google empfiehlt, statt des Standarddienstkontos ein eigenes, vom Nutzer verwaltetes Dienstkonto mit den detailliertesten Berechtigungen zu erstellen und dieses Dienstkonto als Identität Ihres Cloud Run-Dienstes oder -Jobs zu verwenden. In diesem Dokument wird die Konfiguration von dienstspezifischen Identitäten mit Cloud Run beschrieben.

Identität pro Dienst verwenden

Google empfiehlt, jedem Cloud Run-Dienst eine dedizierte Identität zuzuweisen. Dazu weisen Sie ihm ein nutzerverwaltetes Dienstkonto anstelle des Standarddienstkontos zu. Mit von Nutzern verwalteten Dienstkonten können Sie den Zugriff steuern. Dazu weisen Sie minimale Berechtigungen mithilfe der Identitäts- und Zugriffsverwaltung zu.

Die Google Cloud CLI und die Google Cloud-Clientbibliotheken erkennen automatisch, wenn sie auf Google Cloud ausgeführt werden, und verwenden das Laufzeitdienstkonto der aktuellen Cloud Run-Überarbeitung. Das bedeutet, wenn Ihr Code die gcloud CLI oder eine offizielle Google Cloud-Clientbibliothek verwendet, wird er automatisch als Laufzeitdienstkonto des Cloud Run-Dienstes erkannt und authentifiziert. Diese Strategie wird Standardanmeldedaten für Anwendungen genannt und ermöglicht die Portabilität von Code in mehreren Umgebungen

Es gibt zwei Aspekte, um die Identität pro Dienst zuzuweisen:

Erforderliche Berechtigungen zum Zuweisen von nutzerverwalteten Dienstkonten

Wenn Sie einen Cloud Run-Dienst mit einem vom Nutzer verwalteten Dienstkonto bereitstellen möchten, müssen Sie die Identität dieses Dienstkontos (iam.serviceAccounts.actAs) haben. Diese Berechtigung kann über die IAM-Rolle roles/iam.serviceAccountUser erteilt werden. Alle Hauptkonten (z. B. Nutzer, Dienstkonten) müssen diese Berechtigung für das nutzerverwaltete Dienstkonto haben, um einen Cloud Run-Dienst als nutzerverwaltetes Dienstkonto bereitstellen zu können.

Sie können diese Berechtigung über die Google Cloud Console, über die API (YAML) oder über die gcloud CLI so gewähren:

gcloud iam service-accounts add-iam-policy-binding "SERVICE_ACCOUNT_EMAIL" \
    --member "PRINCIPAL" \
    --role "roles/iam.serviceAccountUser"

Ersetzen Sie:

  • SERVICE_ACCOUNT_EMAIL durch die E-Mail-Adresse des Dienstkontos, z. B. PROJECT_NUMBER-compute@developer.gserviceaccount.com.
  • PRINCIPAL durch das Hauptkonto, für das Sie die Bindung hinzufügen. Verwenden Sie das Format user:email, z. B. user:test-user@gmail.com.

Informationen zum Gewähren von Berechtigungen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen.

Neuen Dienst mit einem vom Nutzer erstellten Dienstkonto bereitstellen

Wenn Sie noch kein nutzerverwaltetes Dienstkonto haben, erstellen Sie zuerst ein Dienstkonto.

Sie können das Dienstkonto des Cloud Run-Dienstes mit der Google Cloud Console, der gcloud CLI oder der API (YAML) festlegen, wenn Sie einen neuen Dienst erstellen oder eine neue Überarbeitung bereitstellen:

Console

  1. Rufen Sie in der Google Cloud Console Cloud Run auf.

    Öffnen Sie Cloud Run.

  2. Klicken Sie auf Dienst erstellen, wenn Sie einen neuen Dienst für die Bereitstellung konfigurieren. Wenn Sie einen vorhandenen Dienst konfigurieren möchten, klicken Sie auf den Dienst und dann auf Neue Überarbeitung bearbeiten und bereitstellen.

  3. Wenn Sie einen neuen Dienst konfigurieren, füllen Sie die Seite mit den anfänglichen Diensteinstellungen wie gewünscht aus und klicken Sie dann auf Container, Netzwerk, Sicherheit, um die Seite zur Dienstkonfiguration zu maximieren.

  4. Klicken Sie auf den Tab Sicherheit.

    Bild

    • Klicken Sie auf das Drop-down-Menü Dienstkonto und wählen Sie das gewünschte Dienstkonto aus.
  5. Klicken Sie auf Erstellen oder Bereitstellen.

gcloud

Sie können einen vorhandenen Dienst für ein neues Laufzeitdienstkonto mithilfe des folgenden Befehls aktualisieren:

gcloud run services update SERVICE --service-account SERVICE_ACCOUNT

Ersetzen Sie:

  • SERVICE durch den Namen des Dienstes.
  • SERVICE_ACCOUNT durch das Dienstkonto, das der neuen Identität zugeordnet ist: Dieser Wert ist die E-Mail-Adresse des Dienstkontos, z. B. example@myproject.iam.gserviceaccount.com.

Sie können ein Dienstkonto auch während der Bereitstellung mit dem folgenden Befehl festlegen:

gcloud run deploy --image IMAGE_URL --service-account SERVICE_ACCOUNT

Ersetzen Sie:

  • IMAGE_URL durch einen Verweis auf das Container-Image, z. B. us-docker.pkg.dev/cloudrun/container/hello:latest. Wenn Sie Artifact Registry verwenden, muss das Repository REPO_NAME bereits erstellt sein. Die URL hat die Form REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.
  • SERVICE_ACCOUNT durch das Dienstkonto, das der neuen Identität zugeordnet ist: Dieser Wert ist die E-Mail-Adresse des Dienstkontos, z. B. example@myservice.iam.gserviceaccount.com.

YAML

Sie können vorhandene Dienstkonfigurationen mit dem Befehl gcloud run services describe --format export herunterladen und aufrufen, was bereinigte Ergebnisse im YAML-Format liefert. Anschließend können Sie die unten beschriebenen Felder ändern und die geänderte YAML-Datei mit dem Befehl gcloud run services replace hochladen. Achten Sie darauf, dass Sie die Felder nur wie dokumentiert ändern.

  1. So rufen Sie die Konfiguration auf und laden sie herunter:

    gcloud run services describe SERVICE --format export > service.yaml
  2. Aktualisieren Sie das Attribut serviceAccountName::

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: SERVICE
    spec:
      template:
        spec:
          serviceAccountName: SERVICE_ACCOUNT

    Ersetzen Sie

    • SERVICE durch den Namen Ihres Cloud Run-Dienstes.
    • SERVICE_ACCOUNT durch das Dienstkonto, das der neuen Identität zugeordnet ist: Dieser Wert ist die E-Mail-Adresse des Dienstkontos, z. B. example@myproject.iam.gserviceaccount.com.
  3. Ersetzen Sie den Dienst mit dem folgenden Befehl durch die neue Konfiguration:

    gcloud run services replace service.yaml

Terraform

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

Fügen Sie der vorhandenen Datei main.tf die folgende Ressource hinzu, um ein Dienstkonto zu erstellen:

resource "google_service_account" "cloudrun_service_identity" {
  account_id = "my-service-account"
}

Erstellen oder aktualisieren Sie einen Cloud Run-Dienst und fügen Sie Ihr Dienstkonto hinzu:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloud-run-srv"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    service_account = google_service_account.cloudrun_service_identity.email
  }
}

Dienstkonten in anderen Projekten verwenden

Sie können auch ein nutzerverwaltetes Dienstkonto verwenden, das sich in einem anderen Google Cloud-Projekt als der Cloud Run-Dienst befindet. Wenn sich das Dienstkonto und der Cloud Run-Dienst in verschiedenen Projekten befinden:

  • Für das Projekt, das dieses Dienstkonto enthält, muss die Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage auf Ordnerebene auf "falsch/nicht erzwungen" festgelegt oder dies aus Einstellungen auf Projektebene übernommen werden. Standardmäßig ist dies auf true eingestellt.

  • Das Dienstkonto benötigt eine Rollenmitgliedschaft für roles/iam.serviceAccountTokenCreator für den Dienst-Agent des Bereitstellungsprojekts:

    service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com
    

    Dabei ist PROJECT_NUMBER die Projektnummer für das Projekt.

  • Das Dienstkonto benötigt eine Rollenmitgliedschaft für roles/iam.serviceAccountUser für die Identität (Nutzer oder Automatisierung), die den Bereitstellungsvorgang ausführt.

Sie können Rollenmitgliedschaften direkt auf die Dienstkontoressource anwenden oder von höheren Ebenen in der Ressourcenhierarchie übernehmen.

Berechtigungen, die von Nutzern verwalteten Dienstkonten für den Betrieb von Cloud Run erforderlich sind

Wenn ein Cloud Run-Dienst nicht auf andere Teile von Google Cloud zugreift, muss ihm sein Dienstkonto keine Rollen oder Berechtigungen zuweisen.

Wenn Sie ein neues Dienstkonto über die Google Cloud Console erstellen, ist der optionale Schritt "diesem Dienstkonto Zugriff auf das Projekt erteilen" für zusätzlichen Zugriff. Beispielsweise kann ein Cloud Run-Dienst einen anderen privaten Cloud Run-Dienst aufrufen oder auf eine Cloud SQL-Datenbank zugreifen, die beide IAM-Rollen erfordern. Weitere Informationen finden Sie in der Dokumentation zum Verwalten des Zugriffs.

ID- und Zugriffstokens mit dem Metadatenserver abrufen

Wenn der Code Ihres Cloud Run-Dienstes eine Google Cloud-Clientbibliothek verwendet, ruft die Bibliothek automatisch die Zugriffstokens ab, um die Anfragen Ihres Codes mithilfe des Laufzeitdienstkontos des Dienstes zu authentifizieren.

Wenn Sie stattdessen Ihren eigenen benutzerdefinierten Code verwenden, können Sie den Metadatenserver verwenden, um ID- und Zugriffstokens 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.

Es gibt zwei Arten von Tokens, die Sie mit dem Metadatenserver abrufen können:

Wählen Sie eine der folgenden Optionen aus, um ein Token abzurufen:

Zugriffstokens

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

  1. Verwenden Sie den Compute Metadata Server, 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 authentifiziert werden:

    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 Zugriffstoken, das Sie im vorherigen Schritt abgerufen haben.

    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

Empfehlungen zum Erstellen dedizierter Dienstkonten abrufen

Der Recommender-Dienst gibt automatisch Empfehlungen zum Erstellen eines dedizierten Dienstkontos mit den minimal erforderlichen Berechtigungen.

Weitere Informationen

Zugriff auf Dienste verwalten oder Entwickler, Dienste und Nutzer sicher gegenüber Diensten authentifizieren

Eine Schritt-für-Schritt-Anleitung einer Anwendung, die die Dienstidentität verwendet, um das Sicherheitsrisiko zu minimieren, finden Sie in der Anleitung zum Sichern von Cloud Run-Diensten.