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 Legacy-Dienstkonto von Cloud Build 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 Ihren Sicherheitsstatus verbessern, indem Sie die
Prinzip der geringsten Berechtigung. Im Rahmen dieses Prinzips
empfehlen, ein eigenes Dienstkonto zu erstellen, um Builds auf Ihrem Gerät auszuführen.
So können die potenziellen Auswirkungen von Fehlkonfigurationen oder böswilligen Nutzern reduziert werden.
Auf dieser Seite werden alle Berechtigungen erläutert, die in der Legacy-Version von Cloud Build des Dienstkontos standardmäßig.
Informationen zum Compute Engine-Standarddienstkonto finden Sie unter Standardmäßiges Compute Engine-Dienstkonto
Informationen zum Gewähren oder Widerrufen von Berechtigungen für Cloud Build Standarddienstkonten, siehe Konfigurieren Sie den Zugriff für das Cloud Build-Standarddienstkonto.
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. Dienst
-Konto diese Berechtigungen nur zum Ausführen von Aktionen verwendet, wenn
für die Ausführung Ihres Builds. 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 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:
|
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 |
Darf Logs 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:
|
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, um Artefakte in Artifact Registry zu verwalten. |
artifactregistry.repositories.downloadArtifacts |
Kann Artefakte aus einem Repository in Artifact Registry herunterladen | |
artifactregistry.aptartifacts.create |
Kann Apt-Artefakte in 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 Standort für eine Ressource in Artifact Registry abrufen | |
artifactregistry.locations.list |
Kann unterstützte Standorte für Artifact Registry auflisten | |
artifactregistry.mavenartifacts.get |
Kann Maven-Pakete aus der Artifact Registry abrufen | |
artifactregistry.mavenartifacts.list |
Kann Maven-Pakete aus 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 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 |
Ein gcr.io-Repository in Artifact Registry kann erstellt werden, Image wird an einen gcr.io-Hostnamen im Projekt übertragen. | |
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 zu Tag-Bindungen 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 ein Artefaktanalyse-Vorkommen erstellen | Das Cloud Build-Dienstkonto verwendet diese Berechtigungen nicht, sie sind aber aus Gründen der Abwärtskompatibilität enthalten. |
containeranalysis.occurrences.delete |
Kann ein Artefaktanalysevorkommen löschen | |
containeranalysis.occurrences.get |
Kann ein Artefaktanalyse-Vorkommen abrufen | |
containeranalysis.occurrences.list |
Kann Artefaktanalyse-Vorkommen 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 Trigger mit einem anderen Dienstkonto. Die einzige Ausnahme ist, wenn Ihre für das Projekt das alte Cloud Build-Dienstkonto aktiviert ist, In diesem Fall verwenden Build-Trigger standardmäßig das alte Dienstkonto, wenn kein ein anderes Konto ausgewählt ist.
Nutzerzugriff auf Trigger
Der Nutzerzugriff auf Trigger hängt vom Dienstkontotyp ab, der für den Trigger konfiguriert wurde:
Legacy-Cloud Build-Dienstkonto (falls aktiviert): Jeder Nutzer mit der Rolle „Cloud-Build-Bearbeiter“ kann einen Trigger direkt ausführen. Ein Nutzer kann den Trigger beispielsweise manuell ausführen. Jeder Nutzer mit der Rolle „Cloud Build Editor“ kann Folgendes aktualisieren: Trigger, solange er den Cloud Build- altes Dienstkonto.
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 dieiam.serviceAccounts.actAs
-Berechtigungen für sowohl das zuvor konfigurierte Dienstkonto als auch das neue Dienstkonto die im Trigger festgelegt sind. Um einem Nutzer diese Berechtigung zu erteilen, können Sie Eine vordefinierte Rolle mit der Berechtigung, z. B. die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser
). Alternativ können Sie ein benutzerdefiniertes IAM-Rolle mit der Berechtigungiam.serviceAccounts.actAs
, dann um dem Nutzer diese Rolle zuzuweisen. 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 den Build verwenden Trigger:
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. Beispielsweise können Nutzer indirekt eine werden ausgelöst, wenn neuer Quellcode an ein verbundenes Repository übertragen wird.
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. Cloud Build Das alte Dienstkonto kann nicht zum Generieren von ID-Tokens verwendet werden.
Wenn Sie serverlose Plattformanwendungen wie Cloud Run-Funktionen, Cloud Run oder App Engine und Sie möchten Ihre Anwendung aus Cloud Build. Dazu ist eine benutzerdefinierte Dienstkonto, das mit den erforderlichen Berechtigungen für Dienst-zu-Dienst konfiguriert ist Authentifizierung.
Eine Anleitung finden Sie unter Zugriff von Diensten auf Dienste autorisieren.
Nächste Schritte
- Benutzerdefinierten Dienstkonten
- Zugriff auf das Cloud Build-Standarddienstkonto konfigurieren
- Zugriff auf Cloud Build-Ressourcen konfigurieren
- Weitere Informationen zu den Berechtigungen zum Aufrufen von Build-Logs