Cloud Build-Standarddienstkonto

Abhängig von Ihren Projekteinstellungen kann Cloud Build möglicherweise die Methode Legacy-Dienstkonto von Cloud Build oder das Standardmäßiges Compute Engine-Dienstkonto zum Ausführen von Builds in Ihrem Die E-Mail-Adresse für das alte Cloud Build-Dienstkonto lautet [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com und die E-Mail-Adresse für das Compute Engine-Standarddienstkonto lautet [PROJECT_NUMBER]-compute@developer.gserviceaccount.com. Standarddienstkonten haben möglicherweise Berechtigungen, die für Ihren Anwendungsfall unnötig weit gefasst sind. Sie können Ihre Sicherheitslage verbessern, indem Sie dem Prinzip der geringsten Berechtigung folgen. Gemäß diesem Prinzip empfehlen wir Ihnen, ein eigenes Dienstkonto zu erstellen, um Builds in Ihrem Namen auszuführen. Dies kann die potenziellen Auswirkungen von Fehlkonfigurationen oder schädlichen Funktionen Nutzenden.

Auf dieser Seite werden alle Berechtigungen des Cloud Build-Dienstkontos standardmäßig erläutert.

Informationen zum Compute Engine-Standarddienstkonto finden Sie unter Standardmäßiges Compute Engine-Dienstkonto

Informationen zum Gewähren oder Widerrufen von Berechtigungen für die Cloud Build-Standarddienstkonten finden Sie unter Zugriff für das Cloud Build-Standarddienstkonto konfigurieren.

Standardberechtigungen des Legacy-Cloud Build-Dienstkontos

Wenn die Projekteinstellungen die Verwendung des Cloud Build-Legacy-Dienstkontos zulassen, erhält es die Rolle Cloud Build-Dienstkonto für die Ressourcen im Projekt. Diese Rolle enthält eine Reihe von Berechtigungen, z. B. die Möglichkeit, Builds zu aktualisieren oder Logs zu schreiben. Das Dienstkonto verwendet diese Berechtigungen nur, um die Aktionen beim Ausführen Ihres Builds auszuführen. Das Dienstkonto verwendet beispielsweise die Methode Berechtigung artifactregistry.dockerimages.get zum Abrufen eines Docker-Images aus Container Registry, wenn Ihr Build dafür konfiguriert ist. Wenn Sie nicht vorhaben, während des Build-Prozesses eine Aktion ausgeführt wird, empfehlen wir, dass Sie den eine entsprechende Berechtigung vom Dienstkonto erteilen, Prinzip der geringsten Berechtigung.

In der folgenden Tabelle sind die Berechtigungen aufgeführt, die vom Cloud Build Service Konto enthält und den Zweck, für den die Cloud Build-Anwendung Legacy-Dienstkonto diese Berechtigungen verwendet.

Berechtigung Beschreibung Zweck der Berechtigung
cloudbuild.builds.create Kann Builds und Trigger erstellen Erforderlich für:
  • Verwenden Sie Build-Trigger.
  • Builds erstellen, auflisten, abrufen oder abbrechen.
cloudbuild.builds.update Kann Builds und Trigger aktualisieren
cloudbuild.builds.list Kann Builds und Trigger auflisten
cloudbuild.builds.get Kann einen Build und einen Trigger abrufen
cloudbuild.workerpools.use Kann einen privaten Pool verwenden Erforderlich, um Builds in einem privaten Pool auszuführen.
logging.logEntries.create Kann Logs schreiben Erforderlich zum Erstellen und Auflisten von Build-Logs in Cloud Logging.
logging.logEntries.list Kann Protokolle auflisten
logging.views.access Kann Logs aufrufen
pubsub.topics.create Kann Pub/Sub-Themen erstellen Erforderlich, um Build-Updates an Pub/Sub zu übertragen.
pubsub.topics.publish Kann in Pub/Sub veröffentlichen
remotebuildexecution.blobs.get Kann Builds genehmigen oder ablehnen. Erforderlich, um ausstehende Builds zu genehmigen oder abzulehnen
resourcemanager.projects.get Kann Projektinformationen abrufen
resourcemanager.projects.list Kann Projekte auflisten
source.repos.get Kann Quellcode aus Repositories in Cloud Source Repositories lesen Erforderlich für:
  • Bitbucket- und Cloud Source Repositories-Trigger verwenden.
  • Quellcode aus Cloud Source Repositories abrufen
source.repos.list Kann Repositories in Cloud Source Repositories auflisten
storage.buckets.create Kann Cloud Storage-Buckets erstellen Erforderlich für:
  • Images in Container Registry speichern und abrufen (Eingestellt)
  • Artefakte in Cloud Storage speichern und abrufen
  • Builds manuell über gcloud builds submit senden.
  • Build-Logs im vom Nutzer erstellten Log-Bucket speichern
storage.buckets.get Kann Cloud Storage-Buckets abrufen
storage.buckets.list Kann Cloud Storage-Buckets auflisten
storage.objects.list Kann Cloud Storage-Objekte auflisten
storage.objects.update Kann Cloud Storage-Objekte aktualisieren
storage.objects.create Kann Cloud Storage-Objekte schreiben
storage.objects.delete Kann Cloud Storage-Objekte löschen
storage.objects.get Kann Cloud Storage-Objekte lesen
artifactregistry.repositories.uploadArtifacts Kann Artefakte in Repositories in Artifact Registry hochladen Erforderlich zum Verwalten von Artefakten in Artifact Registry.
artifactregistry.repositories.downloadArtifacts Kann Artefakte aus einem Repository in Artifact Registry herunterladen
artifactregistry.aptartifacts.create Kann Apt-Artefakte in die Artifact Registry hochladen
artifactregistry.dockerimages.get Kann Docker-Images aus Artifact Registry abrufen
artifactregistry.dockerimages.list Kann in Artifact Registry gespeicherte Docker-Images auflisten
artifactregistry.kfpartifacts.create Kann ein KFP-Artefakt in Artifact Registry hochladen
artifactregistry.locations.get Kann Informationen zu einem Speicherort für eine Ressource in Artifact Registry abrufen
artifactregistry.locations.list Kann unterstützte Speicherorte für Artifact Registry auflisten
artifactregistry.mavenartifacts.get Kann Maven-Pakete aus Artifact Registry abrufen
artifactregistry.mavenartifacts.list Kann Maven-Pakete aus der Artifact Registry auflisten
artifactregistry.npmpackages.get Kann npm-Pakete aus Artifact Registry abrufen
artifactregistry.npmpackages.list Kann npm-Pakete aus der Artifact Registry auflisten
artifactregistry.projectsettings.get Kann Projekteinstellungen aus Artifact Registry abrufen
artifactregistry.pythonpackages.get Kann Python-Pakete aus der Artifact Registry abrufen
artifactregistry.pythonpackages.list Kann Python-Pakete aus Artifact Registry auflisten
artifactregistry.yumartifacts.create Kann Yum-Artefakte in Artifact Registry hochladen
artifactregistry.repositories.createOnPush Kann ein gcr.io-Repository in Artifact Registry erstellen, wenn zum ersten Mal ein Image per Push an einen gcr.io-Hostnamen im Projekt übertragen wird.
artifactregistry.repositories.get Kann ein Repository aus Artifact Registry abrufen
artifactregistry.repositories.list Kann Repositories in Artifact Registry auflisten
artifactregistry.repositories.listEffectiveTags Kann Tags für Artefakte in Artifact Registry auflisten Erforderlich zum Verwalten von Tags für Artefakte in Artifact Registry.
artifactregistry.repositories.listTagBindings Kann Informationen zur Tagbindung für Artefakte in Artifact Registry auflisten
artifactregistry.tags.create Kann Tags in Artifact Registry erstellen
artifactregistry.tags.get Kann Tags von Artifact Registry abrufen
artifactregistry.tags.list Kann Tags in Artifact Registry auflisten
artifactregistry.tags.update Kann Tags in Artifact Registry aktualisieren
artifactregistry.versions.list Kann Versionen in Artifact Registry auflisten
artifactregistry.versions.get Kann Versionen in Artifact Registry abrufen
containeranalysis.occurrences.create Kann eine Artefaktanalyse-Instanz erstellen Das Cloud Build-Dienstkonto verwendet diese Berechtigungen nicht, sie sind aber aus Gründen der Abwärtskompatibilität enthalten.
containeranalysis.occurrences.delete Kann Artefaktanalyse-Ereignisse löschen
containeranalysis.occurrences.get Kann ein Artefaktanalyse-Vorkommen abrufen
containeranalysis.occurrences.list Kann Artefaktanalyse-Ereignisse auflisten
containeranalysis.occurrences.update Kann Artefaktanalyse-Ereignisse aktualisieren

Build-Trigger

Wenn Sie Build-Trigger erstellen, müssen Sie das Dienstkonto auswählen, das zum Ausführen des Builds verwendet wird. Sie können jeden Trigger mit einem anderen Dienstkonto konfigurieren. Die einzige Ausnahme ist, wenn das Cloud Build-Legacy-Dienstkonto in Ihrem Projekt aktiviert ist. In diesem Fall wird für Build-Trigger standardmäßig das Legacy-Dienstkonto verwendet, wenn kein anderes Konto ausgewählt ist.

Nutzerzugriff auf Trigger

Der Nutzerzugriff auf Trigger hängt vom Dienstkontotyp ab, der für den Trigger konfiguriert wurde:

  • Altes Cloud Build-Dienstkonto (falls aktiviert): Jeder Nutzer mit der Rolle „Cloud Build-Bearbeiter“ kann einen Trigger erstellen und direkt ausführen. Ein Nutzer kann den Trigger beispielsweise manuell ausführen. Jeder Nutzer mit der Rolle „Cloud Build-Bearbeiter“ kann einen Trigger aktualisieren, solange für den Trigger das alte Cloud Build-Dienstkonto verwendet wird.

  • Vom Nutzer angegebenes Dienstkonto oder das Compute Engine-Standarddienstkonto: Jeder Nutzer mit der Rolle „Cloud-Build-Bearbeiter“, der die Mit der Berechtigung iam.serviceAccounts.actAs kann ein Trigger erstellt und direkt ausgeführt werden. Ein Nutzer kann den Trigger beispielsweise manuell ausführen. Jeder Nutzer mit der Rolle „Cloud Build Editor“ kann Trigger aktualisieren, solange sie die iam.serviceAccounts.actAs-Berechtigungen für sowohl das zuvor konfigurierte Dienstkonto als auch das neue Dienstkonto die im Trigger festgelegt sind. Wenn Sie einem Nutzer diese Berechtigung zuweisen möchten, können Sie ihm eine vordefinierte Rolle mit der Berechtigung zuweisen, z. B. die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser). Alternativ können Sie eine benutzerdefinierte IAM-Rolle mit der Berechtigung iam.serviceAccounts.actAs erstellen und diese Rolle dem Nutzer zuweisen. Weitere Informationen zu Dienstkontoberechtigungen Siehe Rollen für die Dienstkontoauthentifizierung.

Build-Berechtigungen von Triggern

Das für einen Build-Trigger konfigurierte Dienstkonto kann Folgendes bereitstellen: erweiterten Build-Berechtigungen für Nutzer, die einen Build mithilfe von Triggern aufrufen. Dies gilt sowohl für das alte Dienstkonto als auch den benutzerdefinierten Dienst Konten. Beachten Sie die folgenden Auswirkungen auf die Sicherheit, wenn Sie Build-Trigger verwenden:

  • Ein Nutzer ohne Zugriff auf Ihr Google Cloud-Projekt, aber mit Schreibzugriff auf Das mit den Build-Triggern im Projekt verknüpfte Repository hat Berechtigungen um den erstellten Code zu ändern. Nutzer können beispielsweise indirekt einen Trigger aufrufen, wenn sie neuen Quellcode an ein verbundenes Repository senden.

  • Wenn Sie GitHub-Pull-Anfrage-Trigger verwenden, kann jeder Nutzer mit Lesezugriff auf das Repository eine Pull-Anfrage senden. Diese kann einen Build ausführen, der Änderungen am Code in der Pull-Anfrage enthält. Sie können dieses Verhalten deaktivieren, indem Sie beim Erstellen eines GitHub-Pull-Anfrage-Triggers die Option Kommentarsteuerung auswählen. Durch Auswahl dieser Option wird der Build nur gestartet, wenn ein Repository-Inhaber oder ein Mitbearbeiter /gcbrun kommentieren. Informationen zur Verwendung der Kommentarsteuerung mit GitHub-Triggern finden Sie unter GitHub-Trigger erstellen.

Beschränkungen

Wenn Sie sich zwischen Diensten mit einem ID-Token authentifizieren müssen, müssen Sie Ihre Builds mit einem benutzerdefinierten Dienstkonto. Das alte Cloud Build-Dienstkonto kann nicht zum Generieren von ID-Tokens verwendet werden.

Wenn Sie beispielsweise serverlose Plattformanwendungen wie Cloud Run-Funktionen, Cloud Run oder App Engine verwenden und Ihre Anwendung über Cloud Build aufrufen möchten, ist ein vom Nutzer angegebenes Dienstkonto erforderlich, das mit den erforderlichen Berechtigungen für die Dienst-zu-Dienst-Authentifizierung konfiguriert ist.

Eine Anleitung finden Sie unter Zugriff von Diensten auf andere Dienste autorisieren.

Nächste Schritte