Audit the Google Cloud IAM bindings for the Google Cloud Service Account OpenID Connect Identity Token Creator Role and identify every principal that can mint identity tokens for a service account. Validate each grant against business need, look for service accounts used by automation, and remove unnecessary access. Also review related service account usage for suspicious token minting patterns.
What this role actually lets a principal do
The Google Cloud Service Account OpenID Connect identity token creator role is effectively a minting permission. Anyone granted it can create OIDC identity tokens for a service account, which means the audit question is not just “who has access” but “who can impersonate this service account in a way that downstream systems will trust.” In practice, that makes the IAM binding itself the authoritative source of truth.
To inspect it properly, review the service account’s policy and every inherited binding that reaches it through a folder, project, or organization scope. The key is to identify the exact principals, then distinguish direct grants from access granted through groups or higher-level policy inheritance. The same review should cover any automation identities that depend on the service account, because token creation rights often exist to support machine-to-machine workflows.
For the Google Cloud side of the investigation, start with Google Cloud IAM and Service Accounts Guide for the broader role, policy, and service-account context. If you need the underlying protocol layer that makes the token meaningful, OpenID Connect Core 1.0 explains how identity tokens are issued and validated.
How to enumerate holders without missing inherited access
The practical audit path is to query the service account policy, expand group membership, and review any organization or project-level IAM inheritance that can flow down to the account. Do not stop at the obvious direct binding, because a seemingly small group membership can hide many principals with the same effective privilege. If the service account is widely reused, separate the audit by environment and by workload so you can see which bindings are intentional versus copied forward.
A good result is a clean inventory of principals mapped to business justification: human administrators, CI/CD systems, workloads, and third-party integrations. A weak result is a long list of broad groups, legacy automation identities, or shared access paths that nobody can explain. Where token minting is tied to automation, document the owning team and the runtime that depends on the permission so you can tell whether the grant is still required.
Because token creation is a delegated trust decision, it is often useful to cross-check the access pattern against a broader identity governance view such as IAM and IGA Basics. If the same service account spans more than one cloud or trust boundary, Multi-Cloud Identity Guide helps frame why inherited privilege and identity drift become harder to spot at scale.
What to check after you know who has the role
Once you have the list, validate each grant against the workload it supports. The most important question is whether the principal still needs to mint identity tokens, not whether it used to need that access at some point in the past. Remove stale grants, replace broad group assignment with narrower ownership where possible, and treat shared administrative access as a red flag if it is not operationally justified.
You should also review token minting behavior for abnormal use, especially sudden spikes, unusual source locations, or principals minting tokens outside normal deployment windows. If the service account has been reused across environments, that is a common place where audit findings turn into security incidents, because a valid minting permission in one context can be abused to reach another. When the permission supports workload authentication, compare the grant to the actual runtime design rather than the application team’s informal description.
For token-based trust, the most relevant external reference is RFC 6749: The OAuth 2.0 Authorization Framework, with RFC 9700: Best Current Practice for OAuth 2.0 Security as the modern security baseline for protecting token flows from replay and theft.
Risk and Threat Considerations
A token creator grant is a high-value privilege because it can turn a routine service account into a trusted impersonation path. If an attacker or rogue insider gets the role, they may not need the service account’s existing secret material at all, they can simply mint fresh tokens and use them where that service account is trusted.
Failure mechanism: Excessive or inherited IAM bindings allow principals to mint identity tokens far beyond the intended workload or operator set, and those tokens can then be used as trusted authentication material.
Impact: Unauthorized token minting can lead to service-account impersonation, lateral movement, data access, and persistence that is harder to detect than direct secret theft.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Controls service-to-service token minting and trust decisions for this service account role. |
| AC-6 — Least Privilege | The audit is about whether principals have more token-creation access than business need requires. | |
| Recommendation — Restrict service token-creation rights to approved workloads and review inherited grants regularly. Remove unnecessary token-creator bindings and narrow access to the minimum required principals. | ||
| CIS Controls v8 | CIS-5 — Account Management | Auditing holders of a service-account role is an account-governance and access-review task. |
| Recommendation — Inventory account grants, verify ownership, and revoke stale or unjustified access. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | A service account token creator role can become overprivileged if too many principals can mint tokens. |
| NHI-10 — Human Use of NHI | The audit must distinguish intended automation access from risky human use of service-account token minting. | |
| Recommendation — Limit token-creator privileges to the smallest set of approved operators and workloads. Separate human administration from automation paths and flag any human-held token-minting access for review. | ||
Practitioner Guidance
What to verify: Confirm whether each principal with the role is directly assigned, group-derived, or inherited from a higher scope. If you cannot explain the business need in one sentence, treat the binding as suspect until proven otherwise.
Decision rule: If the principal only exists to support automation, keep the permission tightly scoped to that automation boundary and remove it from human or shared admin groups. If the role is used for cross-environment access, require a documented exception with an owner and expiry.
What good looks like: Each service account has a small, explainable set of token creators, the grants map to specific workloads, and token minting activity is reviewable in logs with a clear ownership trail.
Practitioner takeaway: Audit the binding as an impersonation control, not a role label, because the real security question is who can mint a trusted token on behalf of the service account and whether that power is still justified.
Related resources from NHI Mgmt Group
- How do you audit who holds the Google Cloud Service Account Token Creator Role?
- Google Cloud Service Account OpenID Connect Identity Token Creator Role (roles/iam.serviceAccountOpenIdTokenCreator)
- How do you audit who holds the Google Cloud Service Account Key Admin Role?
- How do you audit who holds the Google Cloud Service Account Admin Role?