Depending on your organization's settings, Cloud Build may use the Compute Engine default service account or the legacy Cloud Build service account to execute builds on your behalf.
Default service accounts may have permissions that are unnecessarily broad for your use case. You can improve your 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.
To learn how to grant or revoke permissions to the Cloud Build default service accounts, see Configure access for the Cloud Build default service account .
About the Compute Engine default service account
Your organization's policies might define the default Cloud Build
service account to be the Compute Engine default service account. The
email address for this service account is
PROJECT_NUMBER
-compute@developer.gserviceaccount.com
.
For information on the Compute Engine default service account, see Compute Engine default service account .
About the legacy Cloud Build service account
Your organization's policies might define the default Cloud Build
service account to be the legacy service account. The email for the legacy
Cloud Build service account is PROJECT_NUMBER
@cloudbuild.gserviceaccount.com
This section explains all the permissions that the legacy Cloud Build service account has by default.
Default permissions of the legacy Cloud Build service account
If your project settings allow the use of the legacy Cloud Build
service account, the legacy service account is granted the Cloud Build Service Accountrole
( roles/cloudbuild.builds.builder
) 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 artifactregistry.dockerimages.get
permission to get a docker image from
Artifact Registry, if your build is configured to do so.
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 service account to comply with the security principle of least privilege .
The following table lists the permissions that the Cloud Build
Service Accountrole ( roles/cloudbuild.builds.builder
) contains and the
purpose for which the legacy Cloud Build service account uses these permissions.
cloudbuild.builds.create
- Use build triggers.
- Create, list, get, or cancel builds.
cloudbuild.builds.update
cloudbuild.builds.list
cloudbuild.builds.get
cloudbuild.workerpools.use
logging.logEntries.create
logging.logEntries.list
logging.views.access
pubsub.topics.create
pubsub.topics.publish
remotebuildexecution.blobs.get
resourcemanager.projects.get
resourcemanager.projects.list
source.repos.get
- Use Bitbucket and Cloud Source Repositories triggers.
- Pull source code from Cloud Source Repositories.
source.repos.list
storage.buckets.create
- Store and get artifacts in Cloud Storage.
- Submit builds manually using
gcloud builds submit. - Store build logs in user-created logs bucket.
storage.buckets.get
storage.buckets.list
storage.objects.list
storage.objects.update
storage.objects.create
storage.objects.delete
storage.objects.get
artifactregistry.repositories.uploadArtifacts
artifactregistry.repositories.downloadArtifacts
artifactregistry.aptartifacts.create
artifactregistry.dockerimages.get
artifactregistry.dockerimages.list
artifactregistry.kfpartifacts.create
artifactregistry.locations.get
artifactregistry.locations.list
artifactregistry.mavenartifacts.get
artifactregistry.mavenartifacts.list
artifactregistry.npmpackages.get
artifactregistry.npmpackages.list
artifactregistry.projectsettings.get
artifactregistry.pythonpackages.get
artifactregistry.pythonpackages.list
artifactregistry.yumartifacts.create
artifactregistry.repositories.createOnPush
artifactregistry.repositories.get
artifactregistry.repositories.list
artifactregistry.repositories.listEffectiveTags
artifactregistry.repositories.listTagBindings
artifactregistry.tags.create
artifactregistry.tags.get
artifactregistry.tags.list
artifactregistry.tags.update
artifactregistry.versions.list
artifactregistry.versions.get
containeranalysis.occurrences.create
containeranalysis.occurrences.delete
containeranalysis.occurrences.get
containeranalysis.occurrences.list
containeranalysis.occurrences.update
Build triggers
When creating build triggers , you must choose the service account used to execute the build. You can configure each trigger with a different service account. The only exception is if your project has the legacy Cloud Build service account enabled , in which case build triggers default to using the legacy service account when no other account is selected.
User access to triggers
User access to triggers depends on the service account type configured for the trigger:
-
Legacy Cloud Build service account(if enabled): 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 with the Cloud Build Editor role can update a trigger as long as the trigger is using the Cloud Build legacy service account.
-
User-specified service account or the Compute Engine default service account: Any user with the Cloud Build Editor role who has the
iam.serviceAccounts.actAspermission can create and directly run a trigger. For example, a user can run the trigger manually.Any user with the Cloud Build Editor role can update a trigger as long as they have the
iam.serviceAccounts.actAspermissions 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 Userrole (roles/iam.serviceAccountUser). Alternatively, you can create a custom IAM role with theiam.serviceAccounts.actAspermission, then grant that role to the user. To learn more about service account permissions, see Roles for service account authentication .
Build-time privileges of triggers
The service account configured for a build trigger can provide elevated build-time permissions to users who employ triggers to invoke a build. This applies to both the legacy service account and user-specified service accounts. Keep in mind the following security implications when using build triggers:
-
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. For example, users can indirectly invoke a trigger when they push new source code to a connected repository.
-
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 controloption 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 controlwith GitHub triggers, see Creating GitHub triggers .
Limitations on the legacy Cloud Build service account
-
If you need to authenticate between services using an ID token, you must run your builds with a user-specified service account. You can't use the legacy Cloud Build service account to generate ID tokens.
For example, if you use serverless platform applications such as Cloud Run 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 .
-
You can't add an IAM policy binding on the legacy service account. For example, you can't create an IAM policy binding that grants another service account the
roles/iam.serviceAccountTokenCreatorrole on the legacy service account.
What's next
- Learn about user-specified service accounts .
- Learn about configuring access for the Cloud Build default service account .
- Learn about configuring access to Cloud Build resources .
- Learn about the permissions required to view build logs .
