Cloud Build service account

Cloud Build may use a special service account to execute builds on your behalf. The email for the Cloud Build service account is [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com. This service account may have permissions that are unnecessarily broad for your use case. You can improve the security posture by following the principle of least privilege. As part of this principle, we recommend creating your own service account to execute builds on your behalf, this can reduce the potential impact of misconfigurations or malicious users.

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 Google 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
cloudbuild.workerpools.use Can use a private pool Required to run builds in a private pool.
logging.logEntries.create Can write logs Required to create and list build logs in Cloud Logging.
logging.logEntries.list Can list logs
logging.views.access Can view logs
pubsub.topics.create Can create Pub/Sub topics Required to push build updates to Pub/Sub.
pubsub.topics.publish Can publish to Pub/Sub
remotebuildexecution.blobs.get Can get get access to approve or reject builds. Required to approve or reject pending builds
resourcemanager.projects.get Can get project information
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
storage.buckets.create Can create Cloud Storage buckets Required to:
  • Store and get images in Container Registry ( Deprecated).
  • 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.uploadArtifacts Can upload artifacts to repositories in Artifact Registry Required to manage artifacts in Artifact Registry.
artifactregistry.repositories.downloadArtifacts Can download artifacts from a repository in Artifact Registry
artifactregistry.aptartifacts.create Can upload Apt artifacts to Artifact Registry
artifactregistry.dockerimages.get Can get Docker images from Artifact Registry
artifactregistry.dockerimages.list Can list Docker images stored in Artifact Registry
artifactregistry.kfpartifacts.create Can upload a KFP artifact to Artifact Registry
artifactregistry.locations.get Can get information about a location for a resource in Artifact Registry
artifactregistry.locations.list Can list supported locations for Artifact Registry
artifactregistry.mavenartifacts.get Can get Maven packages from Artifact Registry
artifactregistry.mavenartifacts.list Can list Maven packages from Artifact Registry
artifactregistry.npmpackages.get Can get npm packages from Artifact Registry
artifactregistry.npmpackages.list Can list npm packages from Artifact Registry
artifactregistry.projectsettings.get Can get project settings from Artifact Registry
artifactregistry.pythonpackages.get Can get Python packages from Artifact Registry
artifactregistry.pythonpackages.list Can list Python packages from Artifact Registry
artifactregistry.yumartifacts.create Can upload Yum artifacts to Artifact Registry
artifactregistry.repositories.createOnPush Can create a gcr.io repository in Artifact Registry the first time an image is pushed to a gcr.io hostname in the project.
artifactregistry.repositories.get Can get a repository from Artifact Registry
artifactregistry.repositories.list Can list repositories in Artifact Registry
artifactregistry.repositories.listEffectiveTags Can list tags for artifacts in Artifact Registry Required to manage tags for artifacts in Artifact Registry.
artifactregistry.repositories.listTagBindings Can list tag binding information for artifacts in Artifact Registry
artifactregistry.tags.create Can create tags in Artifact Registry
artifactregistry.tags.get Can get tags from Artifact Registry
artifactregistry.tags.list Can list tags in Artifact Registry
artifactregistry.tags.update Can update tags in Artifact Registry
artifactregistry.versions.list Can list versions in Artifact Registry
artifactregistry.versions.get Can get versions in Artifact Registry
containeranalysis.occurrences.create Can create an Artifact Analysis occurrence Cloud Build service account does not use these permissions, but they're included for backwards compatibility.
containeranalysis.occurrences.delete Can delete an Artifact Analysis occurrence
containeranalysis.occurrences.get Can get an Artifact Analysis occurrence
containeranalysis.occurrences.list Can list Artifact Analysis occurrences
containeranalysis.occurrences.update Can update Artifact Analysis occurrences

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 the iam.serviceAccounts.actAs permission 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 the iam.serviceAccounts.actAs permissions on both the previously configured service account and the new service account specified on the trigger. To give a user this permission, you can grant them a predefined role with the permission, like the Service Account User role (roles/iam.serviceAccountUser). Alternatively, you can create a custom IAM role with the iam.serviceAccounts.actAs permission, then grant that role to the user. To learn more about service account permissions, see Roles for service account authentication.

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 Google 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.

Limitations

If you need to authenticate between services using an ID token, you must run your builds with a user-specified service account. The default Cloud Build service account cannot be used to generate ID tokens.

For example, if you use serverless platform applications such as Cloud Functions, Cloud Run, or App Engine, and you want to invoke your application from Cloud Build, this requires a user-specified service account configured with required permissions for service-to-service authentication.

For instructions, see Authorize service-to-service access.

What's next