Je nach Projekteinstellungen verwendet Cloud Build möglicherweise das alte Cloud Build-Dienstkonto oder das Compute Engine-Standarddienstkonto, um Builds für Sie auszuführen. Die E-Mail-Adresse für das bisherige 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. So können die potenziellen Auswirkungen von Fehlkonfigurationen oder böswilligen Nutzern reduziert werden.
Auf dieser Seite werden alle Berechtigungen des Cloud Build-Dienstkontos standardmäßig erläutert.
Weitere Informationen zum Compute Engine-Standarddienstkonto finden Sie unter Compute Engine-Standarddienstkonto.
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 alten Cloud Build-Dienstkontos
Wenn die Projekteinstellungen die Verwendung des Cloud Build-Legacy-Dienstkontos zulassen, wird ihm die Rolle Cloud Build-Dienstkonto für die Ressourcen im Projekt zugewiesen. 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 artifactregistry.dockerimages.get
, um ein Docker-Image aus der Container Registry abzurufen, wenn Ihr Build so konfiguriert ist. Wenn Sie im Rahmen des Build-Prozesses keine Aktion ausführen möchten, sollten Sie die entsprechende Berechtigung vom Dienstkonto widerrufen, um dem Sicherheitsprinzip der geringsten Berechtigung gerecht zu werden.
In der folgenden Tabelle sind die Berechtigungen aufgeführt, die die Rolle Cloud Build-Dienstkonto enthält, sowie der Zweck, für den das Cloud Build-Legacy-Dienstkonto diese Berechtigungen verwendet.
Berechtigung | Beschreibung | Zweck der Berechtigung |
---|---|---|
cloudbuild.builds.create |
Kann Builds und Trigger erstellen | Erforderlich für:
|
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 nutzen | 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 |
Sie können Zugriff erhalten, um Builds zu genehmigen oder abzulehnen. | Erforderlich zum Genehmigen oder Ablehnen ausstehender Builds |
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:
|
source.repos.list |
Kann Repositories in Cloud Source Repositories auflisten | |
storage.buckets.create |
Kann Cloud Storage-Buckets erstellen | Erforderlich für:
|
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 der 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 der Artifact Registry abrufen | |
artifactregistry.mavenartifacts.list |
Kann Maven-Pakete aus der Artifact Registry auflisten | |
artifactregistry.npmpackages.get |
Kann npm-Pakete aus der 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 der 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 | Diese Berechtigungen werden vom Cloud Build-Dienstkonto nicht verwendet, sind aber aus Gründen der Abwärtskompatibilität enthalten. |
containeranalysis.occurrences.delete |
Kann Artefaktanalyse-Ereignisse löschen | |
containeranalysis.occurrences.get |
Kann ein Artefaktanalyse-Ereignis abrufen | |
containeranalysis.occurrences.list |
Kann Artefaktanalyse-Ereignisse auflisten | |
containeranalysis.occurrences.update |
Kann Artefaktanalyse-Ereignisse aktualisieren |
Build-Trigger
Beim Erstellen von Build-Triggern 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 für Ihr 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 für den Trigger konfigurierten Dienstkontotyp ab:
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.
Benutzerdefiniertes Dienstkonto oder das Compute Engine-Standarddienstkonto: Jeder Nutzer mit der Rolle „Cloud Build-Bearbeiter“ und der Berechtigung
iam.serviceAccounts.actAs
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 er die Berechtigungeniam.serviceAccounts.actAs
für das zuvor konfigurierte Dienstkonto und das neue Dienstkonto hat, das im Trigger angegeben ist. 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 Berechtigungiam.serviceAccounts.actAs
erstellen und diese Rolle dem Nutzer zuweisen. Weitere Informationen zu Dienstkontoberechtigungen finden Sie unter Rollen für die Dienstkontoauthentifizierung.
Build-Berechtigungen für Trigger
Das für einen Build-Trigger konfigurierte Dienstkonto kann Nutzern, die Trigger zum Aufrufen eines Builds verwenden, erhöhte Berechtigungen zum Erstellen von Builds erteilen. Das gilt sowohl für das bisherige Dienstkonto als auch für benutzerdefinierte Dienstkonten. 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 Repository, das mit Build-Triggern im Projekt verknüpft ist, verfügt über Berechtigungen zum Ändern des erstellten Codes. 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 vom Nutzer angegebenen Dienstkonto ausführen. 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 von Cloud Build aus 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
- Benutzerdefinierten Dienstkonten
- Weitere Informationen zum Konfigurieren des Zugriffs für das Cloud Build-Standarddienstkonto
- Zugriff auf Cloud Build-Ressourcen konfigurieren
- Weitere Informationen zu den Berechtigungen zum Aufrufen von Build-Logs