[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[[["\u003cp\u003eCloud Build now recommends using a user-specified service account instead of the default service accounts to enhance security, as default accounts may have overly broad permissions.\u003c/p\u003e\n"],["\u003cp\u003eThe Cloud Build legacy service account, when enabled, has the Cloud Build Service Account role, which includes permissions necessary for build operations like creating, updating, and listing builds and triggers, as well as managing logs and artifacts.\u003c/p\u003e\n"],["\u003cp\u003eUsers with the Cloud Build Editor role can create and directly run triggers associated with the legacy service account, and can update them if they use the legacy account.\u003c/p\u003e\n"],["\u003cp\u003eWhen using build triggers, be aware that users with repository write access can change the built code, and pull requests can initiate builds unless comment control is enabled.\u003c/p\u003e\n"],["\u003cp\u003eThe Cloud Build legacy service account cannot generate ID tokens, therefore if you are using service-to-service authentication, you must use a user-specified service account.\u003c/p\u003e\n"]]],[],null,["# Default Cloud Build service account\n\n| **Note:** We have introduced changes to the default service account used to run builds. As a best practice, we recommend that you [specify your own service\n| account](/build/docs/securing-builds/configure-user-specified-service-accounts) to run your builds. For more information see [Cloud Build default\n| service account change](/build/docs/cloud-build-service-account-updates).\n\nDepending on your organization's settings, Cloud Build may use the\n[Compute Engine default service account](/compute/docs/access/service-accounts#default_service_account) or the legacy\nCloud Build service account to execute builds on your behalf.\n\nDefault service accounts may have permissions that are unnecessarily broad for\nyour use case. You can improve your security posture by following the\n[principle of least privilege](/iam/docs/using-iam-securely). As part of this principle, we\nrecommend [creating your own service account](/build/docs/securing-builds/configure-user-specified-service-accounts) to execute builds on your\nbehalf. This can reduce the potential impact of misconfigurations or malicious\nusers.\n\nTo learn how to grant or revoke permissions to the Cloud Build\ndefault service accounts, see\n[Configure access for the Cloud Build default service account](/build/docs/securing-builds/configure-access-for-cloud-build-service-account).\n\nAbout the Compute Engine default service account\n------------------------------------------------\n\nYour organization's policies might define the default Cloud Build\nservice account to be the Compute Engine default service account. The\nemail address for this service account is \n\n\u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e`-compute@developer.gserviceaccount.com`.\n\nFor information on the Compute Engine default service account, see\n[Compute Engine default service account](/compute/docs/access/service-accounts#default_service_account).\n\nAbout the legacy Cloud Build service account\n--------------------------------------------\n\nYour organization's policies might define the default Cloud Build\nservice account to be the legacy service account. The email for the legacy\nCloud Build service account is \n\n\u003cvar translate=\"no\"\u003ePROJECT_NUMBER\u003c/var\u003e`@cloudbuild.gserviceaccount.com`\n\nThis section explains all the permissions that the legacy Cloud Build\nservice account has by default.\n\n### Default permissions of the legacy Cloud Build service account\n\nIf your project settings allow the use of the legacy Cloud Build\nservice account, the legacy service account is granted the\n**Cloud Build Service Account** role\n(`roles/cloudbuild.builds.builder`) for the resources in the project. This role\ncontains a number of permissions, such as the ability to update builds or write\nlogs. The service account uses these permissions only as required to perform\nactions when executing your build. For example, the service account uses the `artifactregistry.dockerimages.get` permission to get a docker image from\nArtifact Registry, if your build is configured to do so.\n\nIf you don't plan to perform an action as part of the build process, we\nrecommend that you revoke the corresponding permission from the service account\nto comply with the [security principle of least privilege](/iam/docs/using-iam-securely).\n| **Note:** The legacy Cloud Build service account is owned by Google and is not user managed. Because of this, you can't add an IAM policy binding on it, and therefore you can't have another principal (for example, another service account) [generate](/iam/docs/service-account-permissions#token-creator-role) access, ID, or JWT tokens for the legacy Cloud Build service account.\n\nThe following table lists the permissions that the **Cloud Build\nService Account** role (`roles/cloudbuild.builds.builder`) contains and the\npurpose for which the legacy Cloud Build service account uses these permissions.\n\nBuild triggers\n--------------\n\nWhen creating [build triggers](/build/docs/automating-builds/create-manage-triggers),\nyou must choose the service account used to execute the build. You can configure\neach trigger with a different service account. The only exception is if your\nproject has the legacy Cloud Build service account\n[enabled](/build/docs/cloud-build-service-account-updates#disable-sa), in which case build triggers default to using the\nlegacy service account when no other account is selected.\n\n### User access to triggers\n\nUser access to triggers depends on the service account type configured for the\ntrigger:\n\n- **Legacy Cloud Build service account** (if enabled):\n Any user with the Cloud Build Editor role can create and\n directly run a trigger. For example, a user can run the trigger\n manually. Any user with the Cloud Build Editor role can update a\n trigger as long as the trigger is using the Cloud Build\n legacy service account.\n\n- **User-specified service account or the Compute Engine default service account** :\n Any user with the Cloud Build Editor role who has the\n `iam.serviceAccounts.actAs` permission can create and directly run a trigger.\n For example, a user can run the trigger manually.\n\n Any user with the Cloud Build Editor role can\n update a trigger as long as they have the `iam.serviceAccounts.actAs` permissions on\n both the previously configured service account and the new service account\n specified on the trigger. To give a user this permission, you can grant them\n a predefined role with the permission, like the **Service Account User** role\n (`roles/iam.serviceAccountUser`). Alternatively, you can create a custom\n IAM role with the `iam.serviceAccounts.actAs` permission, then\n grant that role to the user. To learn more about service account permissions,\n see [Roles for service account authentication](/iam/docs/service-account-permissions).\n | **Note:** If you use the same service account to trigger and run a build, then that service account must still have the `iam.serviceAccount.actAs` permission.\n\n### Build-time privileges of triggers\n\nThe service account configured for a build trigger can provide\nelevated build-time permissions to users who employ triggers to invoke a build.\nThis applies to both the legacy service account and user-specified service\naccounts. Keep in mind the following security implications when using build\ntriggers:\n\n- A user with no access to your Google Cloud project but with write access to\n the repository associated with build triggers in the project will have permissions\n to change the code being built. For example, users can indirectly invoke a\n trigger when they push new source code to a connected repository.\n\n- If you're using GitHub pull request triggers, any user with\n read access to the repository can submit a pull request, which may trigger a\n build that includes changes to the code in the pull request. You can disable\n this behavior by choosing the **Comment control** option when creating a\n GitHub pull request trigger. Selecting this option will ensure that the build\n is started only if a repository owner or a collaborator comments `/gcbrun`. For\n information on using **Comment control** with **GitHub triggers** , see\n [Creating GitHub triggers](/build/docs/automating-builds/create-github-app-triggers).\n\nLimitations on the legacy Cloud Build service account\n-----------------------------------------------------\n\n- If you need to authenticate between services using an ID token, you must run\n your builds with a user-specified service account. You can't use the legacy\n Cloud Build service account to generate ID tokens.\n\n For example, if you use serverless platform applications such as\n Cloud Run functions, Cloud Run, or App Engine, and you want to invoke\n your application from Cloud Build, this requires a user-specified\n service account configured with required permissions for service-to-service\n authentication.\n\n For instructions, see\n [Authorize service-to-service access](/build/docs/securing-builds/authorize-service-to-service-access).\n- You can't add an IAM policy binding on the legacy service\n account. For example, you can't create an IAM policy binding that\n grants another service account the `roles/iam.serviceAccountTokenCreator`role\n *on* the legacy service account.\n\nWhat's next\n-----------\n\n- Learn about [user-specified service accounts](/build/docs/securing-builds/configure-user-specified-service-accounts).\n- Learn about [configuring access for the Cloud Build default service account](/build/docs/securing-builds/configure-access-for-cloud-build-service-account).\n- Learn about [configuring access to Cloud Build resources](/build/docs/securing-builds/configure-access-to-resources).\n- Learn about [the permissions required to view build logs](/build/docs/securing-builds/store-view-build-logs)."]]
