What are the security risks of assigning the Google Cloud Service Account Token Creator Role?

What makes the Token Creator role risky in practice?

The core risk is delegation, not storage. With the Token Creator role, a principal can mint short-lived access tokens or sign assertions as that service account, which can let it act as the service account without ever knowing the underlying credential material. That creates an impersonation path that is easy to overlook in access reviews because the risky capability is authorization to mint, not possession of a key.

The role also widens the blast radius of any compromise in the caller’s own account. If the caller is abused, the attacker may be able to pivot into workloads, APIs, or downstream systems that trust the service account. That is why the right review question is not only who has the role, but what that role can reach once token minting is exercised.

Because this is fundamentally a Google Cloud IAM delegation right, use the Google Cloud IAM and Service Accounts Guide to map the role to least-privilege design, and compare it with the broader service-account control model in the Service Account Security Guide.

How does abuse usually happen?

Abuse typically starts with an identity that already has a legitimate reason to call the token minting flow, then expands into impersonation, lateral movement, or unauthorized automation. The most dangerous cases are not loud privilege escalations, but quiet use of a valid delegation path from an unexpected user, workload, or network location.

That pattern matters because token minting can bypass the security value of the original credential boundary. If an attacker gets hold of a human account, a CI pipeline, or another service principal with this role, they may not need to steal the service account secret itself. They can simply ask for tokens on demand, which is much harder to distinguish from normal operations unless you already know who should be minting tokens, from where, and for what purpose.

For readers who want the broader non-human identity context behind that abuse pattern, the Ultimate Guide to NHIs explains why service accounts, tokens, and other machine credentials need ownership, lifecycle control, and visibility. The NHI Authentication Guide adds the authentication-side context for token-based delegation and on-behalf-of flows.

What controls reduce the risk without breaking legitimate use?

Use the role only for narrow workflows that truly need delegation, and prefer a design where one team or pipeline cannot freely mint tokens for broadly trusted service accounts. If possible, separate the identity that performs deployment or administration from the identity that owns the target service account, so the minting path is easier to audit and easier to revoke.

Monitor token generation as a security event, not just an authentication event. Look for unusual principals, unfamiliar locations, sudden increases in minting volume, and service accounts that begin issuing tokens to workflows that do not normally use them. If the role is needed for automation, document the approved caller set and review it periodically rather than treating the permission as permanently safe once granted.

For practitioners managing Google Cloud service accounts at scale, the Cloud Workload Identity Guide is the best reference for moving away from static keys and into shorter-lived, more governable patterns. Where the issue is ownership and offboarding, the NHI Ownership and Accountability Guide helps ensure the role has a clear business owner and an accountable reviewer.

Risk and Threat Considerations

This role is attractive because it converts access into authority. A compromised caller may not need to extract a secret, only to request a token or signature operation that the target service account already trusts, which can make abuse look like legitimate delegation until you inspect the source of the mint request.

Failure mechanism: A principal with this role is used as a token minting bridge, so an attacker who compromises that principal can impersonate the service account, access downstream resources, and potentially persist through valid delegation paths.

Impact: The likely consequences are unauthorized access, lateral movement, token replay within the token lifetime, and a much larger blast radius if the service account has broad roles or reaches sensitive production systems.

Practitioner Guidance

What to verify: Confirm exactly which principals can invoke token minting, and test whether each one truly needs that capability for a documented workflow. If a group membership grants the role indirectly, review the group as carefully as the individual account.

Decision rule: If a principal can mint tokens for a production service account but cannot clearly justify that access in an approved automation path, treat it as excess privilege and remove it before chasing lower-priority hardening tasks.

What good looks like: The approved set of callers is small, the service account has a named owner, token generation is logged and reviewed, and unusual minting activity is easy to spot because it stands out from normal deployment or integration behavior.

Practitioner takeaway: The role is dangerous because it grants effective impersonation authority, so the real control objective is to bound and observe delegation, not merely to protect the service account credential itself.

Related resources from NHI Mgmt Group

• What are the security risks of assigning the Google Cloud Service Account Admin Role?
• Google Cloud Service Account Token Creator Role (roles/iam.serviceAccountTokenCreator)
• Google Cloud Service Account OpenID Connect Identity Token Creator Role (roles/iam.serviceAccountOpenIdTokenCreator)
• Why should users not hold Service Account User or Token Creator roles at project level in Google Cloud?