Cloud Build service account

Cloud Build uses a special service account to execute builds on your behalf. The email for the Cloud Build service account is [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com. By default, Cloud Build service account has permissions for performing several tasks such as fetching code from your project's Cloud Source Repositories or writing objects to any Cloud Storage bucket owned by your project. Instead of using the default Cloud Build service account, you can specify your own service account to execute builds on your behalf.

This page explains all the permissions that the Cloud Build service account has by default. To learn how to grant or revoke permissions to the Cloud Build service account, see Configuring access for Cloud Build service account.

Default permissions of Cloud Build service account

When you enable the Cloud Build API for a Cloud project, the Cloud Build service account is automatically created in the project and is granted the Cloud Build Service Account role for the resources in the project. This role contains a number of permissions, such as the ability to update builds or write logs. The service account uses these permissions only as required to perform actions when executing your build. For example, the service account uses the source.repos.get permission to fetch code from your Cloud Source Repositories if the source code for your build is in the Cloud Source Repositories. If you don't plan to perform an action as part of the build process, we recommend that you revoke the corresponding permission from the Cloud Build service account to comply with the security principle of least privilege.

The following table lists the permissions that the Cloud Build service account role contains and the purpose for which the Cloud Build service account uses these permissions.

Permission Description Purpose of the permission
cloudbuild.builds.create Can create builds and triggers Required to:
  • Use build triggers.
  • Create, list, get, or cancel builds.
cloudbuild.builds.update Can update builds and triggers
cloudbuild.builds.list Can list builds and triggers
cloudbuild.builds.get Can get a build and a trigger
storage.buckets.create Can create Cloud Storage buckets Required to:
  • Store and get images in Container Registry.
  • Store and get artifacts in Cloud Storage.
  • Submit builds manually via gcloud builds submit.
  • Store build logs in user-created logs bucket.
storage.buckets.get Can get Cloud Storage buckets
storage.buckets.list Can list Cloud Storage buckets
storage.objects.list Can list Cloud Storage objects
storage.objects.update Can update Cloud Storage objects
storage.objects.create Can write Cloud Storage objects
storage.objects.delete Can delete Cloud Storage objects
storage.objects.get Can read Cloud Storage objects
artifactregistry.repositories.list Can list repositories in Artifact Registry Required to store and get artifacts in Artifact Registry.
artifactregistry.repositories.get Can get a repository from Artifact Registry
artifactregistry.repositories.downloadArtifacts Can download artifacts from a repository in Artifact Registry
artifactregistry.files.list Can list files in Artifact Registry
artifactregistry.files.get Can get files from Artifact Registry
artifactregistry.packages.list Can list packages in Artifact Registry
artifactregistry.packages.get Can get packages from Artifact Registry
artifactregistry.tags.list Can list tags in Artifact Registry
artifactregistry.tags.get Can get tags from Artifact Registry
artifactregistry.versions.list Can list versions in Artifact Registry
artifactregistry.versions.get Can get versions in Artifact Registry
logging.logEntries.create Can write logs Required to create build logs in Cloud Logging.
pubsub.topics.create Can create Pub/Sub topics Required to push build updates to Pub/Sub.
pubsub.topics.publish Can publish to Pub/Sub
resourcemanager.projects.get Can get project information Required to get project information and list projects.
resourcemanager.projects.list Can list projects
source.repos.get Can read source code from repositories in Cloud Source Repositories Required to:
  • Use Bitbucket and Cloud Source Repositories triggers.
  • Pull source code from Cloud Source Repositories.
source.repos.list Can list repositories in Cloud Source Repositories

Build triggers

By default, build triggers use the Cloud Build service account to execute builds. Alternatively, you can configure build triggers to execute builds with a service account of your choice. You can configure each trigger with a different service account.

Keep in mind the following considerations when choosing which service account to specify for a build trigger:

  • Default Cloud Build service account: Any user with the Cloud Build Editor role can create and directly run a trigger. For example, a user can run the trigger manually. Any user can also indirectly run a trigger. For example, a user can indirectly invoke a trigger when they push new source code to a connected repository. Any user with the Cloud Build Editor role can update a trigger as long as the previous service account and new service account specified on the trigger are the default Cloud Build account.

  • User-specified service account: Any user with the Cloud Build Editor role who has impersonation permissions on the service account (iam.serviceAccount.actAs) can create and directly run a trigger. For example, a user can run the trigger manually. Any user can also indirectly run a trigger. For example, a user can indirectly invoke a trigger when they push new source to a connected repository. Any user with the Cloud Build Editor role can update a trigger as long as they have impersonation permissions on both the previously configured service account and the new service account specified on the trigger. You can create a custom IAM role with an impersonation permission or use pre-defined roles that allow members to impersonate a service account. To learn more about impersonation permissions, see Managing service account impersonation.

Additionally, the default Cloud Build service account and user-specified service accounts can provide elevated build-time permissions to users who use triggers to invoke a build. Keep in mind the following security implications when using build triggers associated with the default Cloud Build service account:

  • A user with no access to your Cloud project but with write access to the repository associated with build triggers in the project will have permissions to change the code being built.
  • If you're using GitHub pull request triggers, any user with read access to the repository can submit a pull request, which may trigger a build that includes changes to the code in the pull request. You can disable this behavior by choosing the Comment control option when creating a GitHub pull request trigger. Selecting this option will ensure that the build is started only if a repository owner or a collaborator comments /gcbrun. For information on using Comment control with GitHub triggers, see Creating GitHub triggers.

What's next