Cloud Build kann ein spezielles Dienstkonto verwenden, um Builds in Ihrem Namen auszuführen. Die E-Mail-Adresse für das Cloud Build-Dienstkonto lautet [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com
. Dieses Dienstkonto kann Berechtigungen haben, die für Ihren Anwendungsfall unnötig weit gefasst sind. Sie können den Sicherheitsstatus verbessern, indem Sie dem Prinzip der geringsten Berechtigung folgen. Im Rahmen dieses Prinzips empfehlen wir, ein eigenes Dienstkonto zu erstellen, um Builds in Ihrem Namen auszuführen. Dadurch können die Auswirkungen von Fehlkonfigurationen oder böswilligen Nutzern reduziert 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 Google Cloud-Projekt aktivieren, wird das Cloud Build-Dienstkonto automatisch im Projekt erstellt und erhält für die Ressourcen im Projekt die Rolle „Cloud Build-Dienstkonto“. 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:
|
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 berechtigt sein, 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 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 Artifact Registry abrufen | |
artifactregistry.mavenartifacts.list |
Kann Maven-Pakete aus Artifact Registry auflisten | |
artifactregistry.npmpackages.get |
Kann npm-Pakete von Artifact Registry abrufen | |
artifactregistry.npmpackages.list |
Kann npm-Pakete aus 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 kann in Artifact Registry erstellt werden, wenn ein Image zum ersten Mal 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 Tag-Binding-Informationen 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 Artefaktanalyse-Vorkommen löschen | |
containeranalysis.occurrences.get |
Kann ein Artefaktanalyse-Vorkommen abrufen | |
containeranalysis.occurrences.list |
Kann Artefaktanalyse-Vorkommen auflisten | |
containeranalysis.occurrences.update |
Kann Artefaktanalyse-Vorkommen aktualisieren |
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“ mit der Berechtigung
iam.serviceAccounts.actAs
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. Beispielsweise kann ein Nutzer indirekt einen Trigger auslösen, wenn er eine neue Quelle per Push an ein verbundenes Repository sendet. Jeder Nutzer mit der Rolle „Cloud Build-Bearbeiter“ kann einen Trigger aktualisieren, sofern er die Berechtigungeniam.serviceAccounts.actAs
für das zuvor konfigurierte und das neue Dienstkonto hat, das im Trigger angegeben wurde. Um einem Nutzer diese Berechtigung zu erteilen, 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 dann dem Nutzer zuweisen. Weitere Informationen zu Dienstkontoberechtigungen finden Sie unter Rollen für die Dienstkontoauthentifizierung.
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 Google Cloud-Projekt, der aber Schreibzugriff auf das Repository hat, das Build-Triggern im Projekt zugeordnet ist, hat die Berechtigung, den erstellten Code zu ändern.
- 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 mit einem ID-Token zwischen Diensten authentifizieren müssen, müssen Sie Ihre Builds mit einem benutzerdefinierten Dienstkonto ausführen. Das Cloud Build-Standarddienstkonto kann nicht zum Generieren von ID-Tokens verwendet werden.
Wenn Sie beispielsweise serverlose Plattformanwendungen wie Cloud Functions, Cloud Run oder App Engine verwenden und Ihre Anwendung über Cloud Build aufrufen möchten, benötigen Sie ein benutzerdefiniertes Dienstkonto, das mit den erforderlichen Berechtigungen für die Dienst-zu-Dienst-Authentifizierung konfiguriert ist.
Eine Anleitung dazu finden Sie unter Dienst-zu-Dienst-Zugriff autorisieren.
Nächste Schritte
- Benutzerdefinierten Dienstkonten
- Zugriff für das Cloud Build-Dienstkonto konfigurieren
- Zugriff auf Cloud Build-Ressourcen konfigurieren
- Weitere Informationen zu den Berechtigungen zum Aufrufen von Build-Logs