Google Cloud / Basic: Resource and Access Boundaries / Lesson 4

Service Accounts and Credential Boundaries

Separate deployment identity, runtime identity, credential discovery, and authority to impersonate a service account.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain a service account as both principal and managed resource.
Describe ADC search order without reading credentials.
Prefer short-lived workload identity under an explicit trust relationship.

A service account has two distinct policy relationships

A service account commonly represents an application or compute workload rather than a person. It is a principal when granted access to a bucket, topic, or other resource. It is also a resource on which another principal can receive authority to attach, manage, or impersonate it. Those relationships must be reviewed separately.

A deployer who can configure a workload is not necessarily the identity used by that workload at runtime. Excess authority to act as a powerful service account can indirectly confer the account’s capabilities. Give each workload a deliberately selected identity and review who may use or modify that identity.

Keep deployment and runtime identities visible

The first program checks an invented review record containing separate deployment and runtime names. Distinct strings do not prove least privilege, but an explicit mapping prevents reviewers from silently treating both roles as the interactive user. The model contains no real email, key, token, or credential file.

For an attached service account, supported workloads can obtain credentials through their environment and Google authentication libraries. Attaching an account does not itself grant every service permission. Review the account’s grants, workload configuration, and the caller’s authority to attach it, including product-specific requirements.

python Separate identities in a synthetic review record

review = {"deployment_identity": "release-actor", "runtime_identity": "report-reader"}
assert review["deployment_identity"] != review["runtime_identity"]
print("deployer=" + review["deployment_identity"] + " runtime=" + review["runtime_identity"])

Expected output

deployer=release-actor runtime=report-reader

The local record names two responsibilities; it neither creates accounts nor checks their permissions.

ADC finds credentials through a documented order

Application Default Credentials is a discovery strategy used by Google authentication libraries. Its documented search order considers the GOOGLE_APPLICATION_CREDENTIALS configuration, a local ADC file, then an attached service account through the environment’s metadata mechanism. The gcloud CLI’s own credential state and application ADC are related concepts but not interchangeable evidence of the identity an application actually uses.

The second program selects from static availability flags. It teaches precedence without inspecting environment variables, opening files, or contacting metadata. A higher-precedence local configuration can explain why an application uses a different identity from the attached account. Real diagnosis must identify the source without printing its secrets.

python Model discovery precedence without credentials

sources = [("environment configuration", False), ("local ADC file", True), ("attached identity", True)]
selected = next((name for name, available in sources if available), "none")
print("synthetic source:", selected)

Expected output

synthetic source: local ADC file

The static model chooses the local ADC source before the attached identity; no real credential is loaded.

Short-lived credentials still need a trust design

Workload Identity Federation and service-account impersonation can reduce dependence on downloadable long-lived keys. They do not mean every external token should be trusted. Configure the intended issuer, subject/attribute constraints, target identity, and allowed permissions under the documented product flow. Workforce federation for people is a distinct use case from workload federation for applications.

A service-account key is a credential with its own lifecycle and exposure risk, not merely an ordinary configuration file. Avoid placing real keys in source, images, logs, or examples. Key creation, rotation, revocation, and incident response require authorized ownership. This course does none of those operations and provides no credential material.

Diagnose the identity chain before changing grants

An authentication failure, a failure to impersonate, and a target-service permission denial are different stages. Record which principal requests credentials, which identity results, and which operation is attempted. Audit evidence should identify actors and resources while redacting credential content. A valid token can still lack the target permission or have the wrong audience for the receiving service.

Before an authorized implementation, review identity ownership, permissions, attachment/impersonation rights, credential source, and removal conditions. Test both intended and forbidden cases using approved service-aware methods. The offline examples establish only documentation and model consistency; they cannot prove federation or token acceptance in Google Cloud.

Common errors and fixes

The developer login is assumed to be the runtime identity.

Why it happens: Credential discovery and attached identity were not traced.
How to fix it: Document the actual credential source and resulting principal.
Prevent it next time: Keep deployment, CLI, and application identities separate.

Impersonation is granted broadly to fix one service error.

Why it happens: Authority over the service account is confused with its target permissions.
How to fix it: Diagnose the failing stage and grant only justified authority.
Prevent it next time: Review both sides of the identity relationship.

A key file is copied into a container image.

Why it happens: A long-lived credential is treated as harmless configuration.
How to fix it: Design an approved workload identity mechanism and credential lifecycle.
Prevent it next time: Keep real credentials out of artifacts and examples.

Check your understanding

1. A Cloud Run workload has an attached reader account, but application logs show another principal. What is a disciplined first investigation?

Show worked solution

Trace the authentication library’s credential source and precedence without printing secrets. A higher-priority environment configuration or local ADC source can override the expected discovery path. Distinguish the deployer from the runtime account, then inspect authorized evidence of the resulting principal and token audience. Do not immediately broaden the reader account’s permissions when the application may not be using it.

2. Why is replacing a long-lived key with federation not enough to finish the security review?