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:
- Welche Berechtigungen sind erforderlich, um die Identität pro Dienst zuzuweisen?
- Welche Berechtigungen muss die zugewiesene Identität selbst haben.
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
Rufen Sie in der Google Cloud Console Cloud Run auf.
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.
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.
Klicken Sie auf den Tab Sicherheit.
- Klicken Sie auf das Drop-down-Menü Dienstkonto und wählen Sie das gewünschte Dienstkonto aus.
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 FormREGION-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.
So rufen Sie die Konfiguration auf und laden sie herunter:
gcloud run services describe SERVICE --format export > service.yaml
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
.
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:
Erstellen oder aktualisieren Sie einen Cloud Run-Dienst und fügen Sie Ihr Dienstkonto hinzu:
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 auftrue
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:
- OAuth 2.0-Zugriffstokens, die zum Aufrufen der meisten Google APIs verwendet werden.
- ID-Tokens, die zum Aufrufen anderer Cloud Run-Dienste oder Cloud Functions oder anderer Dienste, die ID-Token validieren.
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
.
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.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: BearerACCESS_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.