How do you audit who holds the Google Cloud Service Account Token Creator Role?

What the Token Creator role actually gives a principal

The Google Cloud Service account token creator role is powerful because it turns permission into impersonation. A principal with this binding can mint short-lived service account tokens and act as that service account for downstream calls, so the security question is not just “who has the role?” but “which service account authority does that role unlock?” That distinction is what makes the audit meaningful.

To understand the exposure, start by mapping each binding to the exact service account it can impersonate, then trace whether that access reaches production systems, sensitive APIs, or privileged automation paths. When the role is inherited through groups, folders, or projects, the effective access can be broader than the visible binding suggests, so the audit has to follow the policy chain, not only the project-level grant.

Use the access review as both a permissions check and a business-justification check. A documented workflow is the right test for ongoing need, because token creation can function as a credential substitute without giving the holder the underlying secret material. That makes it especially important to separate routine operational impersonation from ad hoc or convenience-driven access.

For a broader control model, NHIMG’s Google Cloud IAM and Service Accounts Guide covers role inheritance, impersonation, and least-privilege patterns that help make the audit repeatable.

How to trace holders and impersonation paths

Auditing this role is easiest when you treat it as two linked questions: who can call the permission, and what can they become once they do. Start with all principals that hold the binding directly, then expand to group-based grants, service account policy bindings, and any higher-level inheritance that resolves into the same effective right. The result should be a complete principal-to-target map, not just a list of usernames.

Next, pair each principal with the service account or accounts they can impersonate, because the blast radius is often determined by the target identity rather than the holder. A single holder may be acceptable for one narrowly scoped workload and dangerous for another if the impersonated account has broad API access, data-plane access, or deployment privileges. That is why the audit should classify each binding by use case, sensitivity, and whether the access is human-operated or machine-operated.

For cloud workload identity patterns, NHIMG’s Cloud Workload Identity Guide helps distinguish short-lived, intended delegation from standing access that should be redesigned.

If the environment includes service accounts used by automation, consider whether the holder is actually a human operator, a deployment pipeline, or another workload. The control decision changes depending on which class of actor is requesting token creation, because human use tends to drift into exception handling while workload use should usually be scoped, instrumented, and time-bounded.

What good audit evidence looks like

A strong audit trail shows more than role membership. It should show who granted the binding, when it was last reviewed, which service account it targets, and why the holder still needs impersonation rights. If those facts are missing, the access may be technically valid but operationally unjustified.

Look for evidence that the binding is deliberately limited, such as narrow group membership, dedicated admin groups, separate environments, and clear ownership of the impersonated service account. Also check whether the same principal can mint tokens for multiple service accounts, because that pattern often reveals privilege concentration that should be reduced or segmented.

When service accounts are long-lived or heavily reused, the audit should also verify whether token creation is being paired with other compensating controls such as logging, conditional access, or workflow approval. NHIMG’s Service Account Security Guide is useful here because it frames ownership, governance, and rotation as part of the audit evidence, not just account hygiene.

Watch for unusual token minting activity as an operational signal, especially if a principal normally uses the role rarely or only in a defined change window. Sudden increases in token creation, use from an unexpected network path, or impersonation of a different service account than usual should be treated as a review trigger rather than routine noise.

Risk and Threat Considerations

This role creates a real escalation path because compromise of the holder can immediately become compromise of the impersonated service account. If the target service account has broad cloud access, the attacker may not need the original credentials at all, only the ability to mint tokens on demand.

Failure mechanism: Excessive or poorly reviewed Token Creator bindings let an attacker or careless insider mint valid service account tokens, impersonate a higher-privileged identity, and extend access into production systems or data paths that were not intended for the original principal.

Impact: The main consequence is privilege expansion without obvious credential theft, which can delay detection and make access look legitimate in logs unless the impersonation path is being monitored closely.

For a well-documented example of why service account impersonation matters, NHIMG’s Dropbox Sign breach 2024 shows how back-end service account exposure can translate into broader compromise of keys, tokens, and protected data.

Practitioner Guidance

What to verify: Confirm that every Token Creator binding maps to a named workflow owner, an explicit target service account, and a review date. If any of those three pieces is missing, treat the binding as provisional rather than justified.

Decision rule: If the holder does not need to mint tokens for an operational dependency that is documented and time-bounded, remove the role or move the workflow to a narrower delegation model. If the role is needed for automation, make the automation identity the only holder and keep human access out of the path.

What practitioners underestimate: The dangerous part is often not the holder count, but the privilege of the target service account. A small number of holders can still create a large blast radius if the impersonated account reaches multiple projects, data stores, or deployment controls.

Practitioner takeaway: Audit Token Creator as an impersonation capability, not as a simple IAM grant, and judge it by the sensitivity of the service account it unlocks, the workflow that justifies it, and the telemetry that proves it is actually being used as intended.

Related resources from NHI Mgmt Group

• How do you audit who holds the Google Cloud Service Account Key Admin Role?
• What are the security risks of assigning the Google Cloud Service Account Token Creator Role?
• Google Cloud Service Account Token Creator Role (roles/iam.serviceAccountTokenCreator)
• Google Cloud Service Account OpenID Connect Identity Token Creator Role (roles/iam.serviceAccountOpenIdTokenCreator)