What should be used instead of the Google Cloud Service Account OpenID Connect Identity Token Creator Role for least privilege?

What should replace the Google Cloud Service Account OpenID Connect Identity Token Creator Role?

The better replacement is the smallest permission set that can mint only the specific token type and audience required for that workflow. In practice, that usually means narrowing who can issue identity tokens, limiting where they can be used, and preferring a custom role over a broad predefined role when the use case is well understood and stable.

Why least privilege matters for token creation

Identity tokens are not just another API artifact, they can stand in for trusted workloads and unlock downstream access. That is why broad token-creation permissions are risky: if the role is too wide, a compromised automation path can mint tokens that look legitimate and reuse them across systems. The general control objective is to apply Google Cloud IAM and service account least privilege, not to treat token minting as a convenience permission.

When the required workflow is narrowly defined, a custom role or a narrower predefined role can reduce blast radius without changing the application design. If the workflow depends on identity tokens for on-behalf-of access or federation-style exchange, the boundary should be explicit and reviewed rather than inherited from a broad service account role. The underlying model is the same one described in the OpenID Connect Core 1.0 specification, where token issuance is part of a trust relationship, not a generic entitlement.

How to scope token issuance without overgranting

Start from the exact workflow that needs the token, then ask what the caller must do at mint time, what the token must represent, and where the token will be accepted. If the answer is only one service, one audience, and one automation path, a custom role is usually the cleanest fit. If the use case spans multiple workloads or environments, separate those paths instead of broadening a single role.

A good replacement also includes lifecycle discipline. When the automation or integration no longer needs to mint tokens, remove the permission entirely rather than leaving a dormant entitlement in place. That pattern aligns with the same access-governance logic used in NHI lifecycle management, where provisioning, rotation, and offboarding are part of access control, not afterthoughts.

If the token is only needed to bridge one service to another, prefer a constrained issuance pattern over a standing broad role. The RFC 8693: OAuth 2.0 Token Exchange model is a useful reference point when delegation or impersonation is involved, because it keeps the authority path explicit instead of implicit.

When to tighten further or redesign the workflow

If multiple teams need the same role because the workflow is hard to disentangle, that is usually a sign the token-creation boundary is too coarse. Redesign before reuse becomes policy drift. In cloud environments, the safest pattern is often to separate issuance, consumption, and administrative control so that no single principal can both mint broadly and use broadly.

Where you need a formal external benchmark, NIST SP 800-207 Zero Trust Architecture reinforces the same principle of verifying access at the point of use rather than trusting broad standing privilege. For Google Cloud deployments, the practical takeaway is to prefer the narrowest role that still supports the exact token workflow, then verify that the application can function without broader identity-token privileges.

Risk and Threat Considerations

Broad identity-token creation rights can turn a single service account compromise into reusable access across trusted systems. The failure is usually not the token itself, but the combination of excessive issuance rights, weak separation of duties, and long-lived automation that nobody revisits after deployment.

Failure mechanism: An attacker or unintended insider with token-creation permission can mint valid identity tokens for a trusted workload, then use those tokens to reach systems that accept the token as proof of authority.

Impact: That can enable unauthorized API calls, lateral movement, data access, and persistence through a trusted automation path, even when passwords or interactive login are otherwise well controlled.

Practitioner Guidance

What to verify: Confirm the exact token workflow, the expected audience, and whether the principal truly needs minting permission or only needs to consume a token already issued elsewhere. If the answer is unclear, treat the permission as overbroad until proven otherwise.

Decision rule: If the service account only supports one integration, use a custom role or narrower predefined permission set; if it supports multiple distinct trust paths, split the paths instead of expanding one shared role.

Practitioner takeaway: Least privilege here is not about finding a smaller named role, it is about proving that token issuance is constrained to the smallest possible trust boundary and removed when the workflow ends.

Related resources from NHI Mgmt Group

• What should be used instead of the Google Cloud Service Account Creator Role for least privilege?
• How do you audit who holds the Google Cloud Service Account OpenID Connect Identity Token Creator Role?
• Google Cloud Service Account OpenID Connect Identity Token Creator Role (roles/iam.serviceAccountOpenIdTokenCreator)
• What should be used instead of the Google Cloud Service Account API Key Binding Admin Role for least privilege?