Cloud Build default service account change

Cloud Build automatically selects the Cloud Build service account to execute builds on your behalf, unless you override this behavior. This default service account may have permissions that are unnecessarily broad for your use case, such as access to Container Registry repositories and any Cloud Storage bucket in your project.

The default behavior for how Cloud Build uses service accounts in new projects was changed over several weeks in May and June 2024. These changes improve the default security posture of our customers going forward. You can opt out of these changes by configuring the organization policy constraint.

Before this change, Cloud Build used a Cloud Build-specific service account as the default, now referred to as the Cloud Build legacy service account.

After this change, Cloud Build now uses the Compute Engine default service account as the default service account.

How your projects are impacted depends on whether you're part of an organization:

  • Projects without an organization. If you run the first build in your project after the change, that project will use the Compute Engine service account by default for builds submitted using the Cloud Build API or the Google Cloud CLI. These projects won't have the option to use the Cloud Build legacy service account, but can use a user-specified service account.

  • Projects with an organization. If you run the first build in your project after the change, that project will use the Compute Engine service account by default for builds submitted using the Cloud Build API or the Google Cloud CLI. You can use a user-specified service account or opt out of the change by enabling the Cloud Build service account in your organization.

  • Existing projects without an organization. If you ran the first build in your project before the change, that project will continue with the old behavior, using the Cloud Build legacy service account by default for all your builds. You can continue to use a user-specified service account, by either selecting the Compute Engine service account or creating your own.

  • Existing projects with an organization. If you ran the first build in your project before the change, that project will continue with the old behavior, using the Cloud Build legacy service account by default. You can also continue to use a user-specified service account.

  • Triggering. You'll have to specify a service account when you create or update a trigger, unless the default service account for your project is the Cloud Build legacy service account.

  • Cloud Build service account name: The Cloud Build service account will be referred to as the Cloud Build legacy service account.

What do you need to do?

If you are part of an organization, your organization can configure the behavior of all the projects by setting up an organization policy with the chosen constraints.

Your organization can opt out of these changes by setting the following organization policy boolean constraints:

  • Not Enforced: constraints/cloudbuild.disableCreateDefaultServiceAccount
  • Not enforced: constraints/cloudbuild.useComputeServiceAccount
  • Enforced: constraints/cloudbuild.useBuildServiceAccount

If you can't or don't want to adjust the organization policy, and you enable the Cloud Build API after the change, validate that the either the Compute Engine default service account or your user-created service account has enough permissions for your build. In particular, the user submitting the build must have the iam.serviceAccounts.actAs permission on the service account.

New organization policy constraints

Cloud Build has introduced new organization policy boolean constraints to configure:

  • The ability to use the Cloud Build legacy service account.
  • The default service account for all the projects in an organization.

To modify organization policies, you can use Google Cloud console or the Google Cloud CLI:

To learn more about organization policies see the Introduction to the Organization Policy Service.

Configure availability of the Cloud Build legacy service account

To configure the availability of the Cloud Build legacy service account when you enable the Cloud Build API, Cloud Build will introduce the following boolean policy constraint:

  • Not enforced: constraints/cloudbuild.disableCreateDefaultServiceAccount. Allows the use of the Cloud Build legacy service account in new projects.

  • Enforced: constraints/cloudbuild.disableCreateDefaultServiceAccount. Disables the use of the Cloud Build legacy service account in new projects. This is the default value of the constraint.

This constraint only affects projects that run their first build after the change rolled out. If you decide to not enforce the policy constraint, the change is permanent for all the projects that run their first build when that configuration is active. You can't toggle off the availability of the Cloud Build legacy service account on a project where the service account was previously available. However, even if the service account is available, you can prevent users in your organization from using it, as described in the following section.

As with all org policies and constraints, you can set these policies at the organization level, or at the project level.

Configure the default service account for an organization

To configure which default service account is used in an organization, Cloud Build is introducing two new policy boolean constraints:

  • constraints/cloudbuild.useBuildServiceAccount: Configure the use of the Cloud Build legacy service account.
  • constraints/cloudbuild.useComputeServiceAccount: Configure the use of the Compute Engine default service account.

You can configure these policies independently from each other, but are most useful when the enforcement rules are combined in the following scenarios:

  • Use the Compute Engine default service account, for both manually submitted builds and triggered builds. Set the following constraints in your organization policy:

    • Not enforced: constraints/cloudbuild.useBuildServiceAccount
    • Enforced: constraints/cloudbuild.useComputeServiceAccount

  • Use a user-specified service account, for both manually submitted builds and triggered builds. This is generally the most secure option. Set the following constraints in your organization policy:

    • Not enforced: constraints/cloudbuild.useBuildServiceAccount
    • Not enforced: constraints/cloudbuild.useComputeServiceAccount

  • Continue using the Cloud Build legacy service account. If you are aware of the security trade-offs involved, set the following constraints in your organization policy:

    • Not Enforced: constraints/cloudbuild.disableCreateDefaultServiceAccount
    • Not enforced: constraints/cloudbuild.useComputeServiceAccount
    • Enforced: constraints/cloudbuild.useBuildServiceAccount

  • Continue using the Cloud Build legacy service account for projects that have enabled the Cloud Build API before the change, and start using the Compute Engine default service account for new projects. Make sure you understand the security trade-offs involved, set the following constraints in your organization policy:

    • Enforced: constraints/cloudbuild.disableCreateDefaultServiceAccount
    • Enforced: constraints/cloudbuild.useComputeServiceAccount
    • Enforced: constraints/cloudbuild.useBuildServiceAccount

Get the current default service account for a project

To determine which service account Cloud Build is using as default for a project, you can use Google Cloud CLI or the Cloud Build API:

gcloud CLI

Run the following command to get the default service account for the current project:

gcloud builds get-default-service-account

Cloud Build API

Use cURL to call the Cloud Build API:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/defaultServiceAccount

Replace the placeholder values with the following: