Cloud Build-Dienstkonto

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Cloud Build verwendet ein spezielles Dienstkonto, um Builds für Sie auszuführen. Die E-Mail-Adresse für das Cloud Build-Dienstkonto lautet [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com. Standardmäßig hat das Cloud Build-Dienstkonto Berechtigungen zum Ausführen von Aufgaben, z. B. das Abrufen von Code aus den Cloud Source Repositories Ihres Projekts oder das Schreiben von Objekten in einen Cloud Storage-Bucket Ihres Projekts. Anstatt das standardmäßige Cloud Build-Dienstkonto zu verwenden, können Sie ein eigenes Dienstkonto angeben, damit Builds in Ihrem Namen ausgeführt werden.

Auf dieser Seite werden alle Berechtigungen des Cloud Build-Dienstkontos standardmäßig erläutert. Informationen zum Gewähren oder Widerrufen von Berechtigungen für das Cloud Build-Dienstkonto finden Sie unter Zugriff für das Cloud Build-Dienstkonto konfigurieren.

Standardberechtigungen des Cloud Build-Dienstkontos

Wenn Sie die Cloud Build API für ein Cloud-Projekt aktivieren, wird das Cloud Build-Dienstkonto automatisch im Projekt erstellt und erhält die Cloud Build-Dienstkontorolle 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. Beispielsweise verwendet das Dienstkonto die Berechtigung source.repos.get, um Code aus Ihren Cloud Source Repositories abzurufen, wenn sich der Quellcode für Ihren Build in Cloud Source Repositories befindet. Wenn Sie im Rahmen des Build-Prozesses keine Aktion ausführen möchten, sollten Sie die entsprechende Berechtigung vom Cloud Build-Dienstkonto widerrufen, um dem Sicherheitsprinzip der geringsten Berechtigung. gerecht zu werden.

In der folgenden Tabelle sind die Berechtigungen aufgeführt, die die Rolle des Cloud Build-Dienstkontos enthält, sowie der Zweck, für das das Cloud Build-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
storage.buckets.create Kann Cloud Storage-Buckets erstellen Erforderlich für:
  • Images in Container Registry speichern und abrufen.
  • 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 Artefakte in Repositories in Artifact Registry hochladen Erforderlich, um Artefakte in Artifact Registry hochzuladen und abzurufen.
artifactregistry.repositories.list Kann Repositories in Artifact Registry auflisten
artifactregistry.repositories.get Kann ein Repository aus Artifact Registry abrufen
artifactregistry.repositories.downloadArtifacts Kann Artefakte aus einem Repository in Artifact Registry herunterladen
artifactregistry.files.list Kann Dateien in Artifact Registry auflisten
artifactregistry.files.get Kann Dateien aus der Artifact Registry abrufen
artifactregistry.packages.list Kann Pakete in Artifact Registry auflisten
artifactregistry.packages.get Kann Pakete aus der Artifact Registry abrufen
artifactregistry.tags.create Kann Tags in Artifact Registry erstellen
artifactregistry.tags.update Kann Tags in Artifact Registry aktualisieren
artifactregistry.tags.list Kann Tags in Artifact Registry auflisten
artifactregistry.tags.get Kann Tags von Artifact Registry abrufen
artifactregistry.versions.list Kann Versionen in Artifact Registry auflisten
artifactregistry.versions.get Kann Versionen in Artifact Registry abrufen
logging.logEntries.create Kann Logs schreiben Erforderlich zum Erstellen von Build-Logs in Cloud Logging
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
resourcemanager.projects.get Kann Projektinformationen abrufen Erforderlich, um Projektinformationen abzurufen und Projekte aufzulisten.
resourcemanager.projects.list Kann Projekte auflisten
containeranalysis.occurrences.create Kann ein Container Analysis-Ereignis erstellen Das Cloud Build-Dienstkonto verwendet diese Berechtigungen nicht, sie sind jedoch aus Gründen der Abwärtskompatibilität enthalten.
containeranalysis.occurrences.delete Kann ein Container Analysis-Ereignis löschen
containeranalysis.occurrences.get Kann ein Container Analysis-Ereignis abrufen
containeranalysis.occurrences.list Kann Container Analysis-Ereignisse auflisten
containeranalysis.occurrences.update Kann Container Analysis-Ereignisse aktualisieren
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

Build-Trigger

Standardmäßig verwenden Build-Trigger das Cloud Build-Dienstkonto, um Builds auszuführen. Alternativ können Sie Build-Trigger konfigurieren, um Builds mit einem Dienstkonto Ihrer Wahl auszuführen. Sie können jeden Trigger mit einem anderen Dienstkonto konfigurieren.

Beachten Sie bei der Auswahl des Dienstkontos für einen Build-Trigger folgende Punkte:

  • Standardmäßiges Cloud Build-Dienstkonto: 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 kann auch indirekt einen Trigger ausführen. Ein Nutzer kann beispielsweise indirekt einen Trigger aufrufen, wenn er neuen Quellcode an ein verbundenes Repository sendet. Jeder Nutzer mit der Rolle "Cloud Build-Bearbeiter" kann einen Trigger aktualisieren, solange das vorherige Dienstkonto und das neue auf dem Trigger angegebene Dienstkonto das Standard-Cloud Build-Konto sind.

  • Benutzerdefiniertes Dienstkonto: Jeder Nutzer mit der Rolle „Cloud Build-Bearbeiter”, der Identitätsberechtigungen für das Dienstkonto (iam.serviceAccount.actAs) hat, kann einen Trigger erstellen und direkt ausführen. Ein Nutzer kann den Trigger beispielsweise manuell ausführen. Jeder Nutzer kann auch indirekt einen Trigger ausführen. Ein Nutzer kann beispielsweise indirekt einen Trigger aufrufen, wenn er eine neue Quelle an ein verbundenes Repository sendet. Jeder Nutzer mit der Rolle „Cloud Build-Bearbeiter” kann einen Trigger aktualisieren, solange er Berechtigungen für den Identitätswechsel beim sowohl zuvor konfigurierten Dienstkonto als auch beim neuen Dienstkonto hat, das im Trigger angegeben ist. Sie können eine benutzerdefinierte IAM-Rolle mit einer Berechtigung zum Identitätswechsel erstellen oder vordefinierte Rollen verwenden, mit denen Hauptkonten die Identität eines Dienstkontos wechseln können. Weitere Informationen zu Berechtigungen für den Identitätswechsel finden Sie unter Identitätswechsel für Dienstkonten verwalten.

Darüber hinaus können das Cloud Build-Standarddienstkonto und die benutzerdefinierten Dienstkonten Nutzern, die Trigger zum Aufrufen eines Builds verwenden, erhöhte Berechtigungen zum Erstellen von Builds erteilen. Beachten Sie die folgenden Auswirkungen auf die Sicherheit, wenn Sie Build-Trigger verwenden, die mit dem Cloud Build-Standarddienstkonto verknüpft sind:

  • Ein Nutzer ohne Zugriff auf Ihr Cloud-Projekt, aber mit Schreibzugriff auf das Repository, das mit Build-Triggern im Projekt verknüpft ist, verfügt über Berechtigungen zum Ändern des erstellten Codes.
  • 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.

Nächste Schritte