A pipeline can use more than one identity
The person starting a build, the account executing build steps and the runtime identity attached to the deployed application are different responsibilities. A permission error must be investigated against the principal that made the denied request. Giving the initiating user more access will not necessarily change what the build can do.
Google recommends deliberately configuring build service accounts and documents changes to default identity behavior. A pipeline should therefore record its selected service account rather than relying on an old assumption about the default. Deployment can also require permission to act as another identity; that is a separate boundary from permission to publish an image.
Make the first pipeline auditable
- Document repository, approved branch, build configuration and build account. Separate untrusted changes from a release path that can access protected resources.
- List the resources each step reads or writes, including source, artifacts, secrets, logs and deployment targets. Assign permissions to the correct identity at the appropriate scope.
- Configure log storage and retention compatible with the selected build account. Test both a successful build and a denied action outside the intended scope.
Choose a non-production target for the initial rehearsal. Build logs need to retain useful evidence without printing secret values, tokens or an entire environment.
Illustrative incident: image publishing works, deployment fails
A build account can write a container artifact but cannot act as the runtime service account required by the deployment step. The image is published successfully, and the next step fails. This is an illustrative scenario. Granting project-wide ownership would conceal which permission was missing and create a much broader deployment capability than required.
Identify the first denied operation
Start at the earliest failed step, not the final pipeline summary. Record its principal, requested permission, target resource and sanitized error. Compare those details with the expected identity map. A later 'artifact not found' error may simply be a consequence of an earlier build failure.
| Observation | Evidence to review | Ownership boundary |
|---|---|---|
| Build cannot read a source or secret | Account executing that step | Build access |
| Image upload is denied | Repository path and writer identity | Artifact publication |
| Deployment cannot attach runtime identity | Denied act-as request | Identity delegation |
| Logs cannot be written | Configured logging destination and permissions | Operational evidence |
Review whether the build used a user-specified account or an inherited default. A service agent used by the platform should not be casually replaced with a normal build account. If the failure follows an organization-policy change, involve the policy owner with the exact denied operation.
Apply a scoped correction and preserve the trust model
Have the resource owner approve the intended access and grant only the missing capability needed by the pipeline. Keep delegation scoped to the runtime identity the project is allowed to use. Do not solve a permission error by moving a deployment credential into repository source or by giving a pull-request job the same privileges as a protected release job.
Rerun the same commit through the approved branch path. Confirm that the correct artifact digest reaches the intended non-production target and that the application's runtime identity remains the expected one. Retest a deliberately disallowed target so the correction has a demonstrable boundary.
Operating objectives and handover
Track build failures by stage and permission-denial category. An illustrative internal objective could require every production-capable pipeline to have a reviewed identity map and a successful denied-path test. This is a governance acceptance criterion, not a provider SLA or a claim about deployment speed.
The SOP should retain build ID, commit, executing account, denied permission, approved correction and rollback record. Escalate changes that permit new runtime identities or protected targets. Revisit the map whenever a pipeline adds a secret, artifact repository or deployment environment.
Clouvenix can scope DevOps automation with explicit release and identity boundaries.
Technical reference
Google Cloud: troubleshoot build errors, configure a user-specified build account and default build-account access. Reviewed 19 October 2026.