What should replace the Google Cloud Service Account Key Admin role for least privilege?

Use the minimum permissions needed to manage keys, or avoid key management entirely where workloads can use keyless authentication. The Service Account Key Admin role can allow creation and lifecycle control of long-lived credentials, so defenders should restrict it tightly, prefer short-lived credentials, and monitor for unnecessary key creation.

Why least privilege means replacing broad key administration with narrower control

The question is not whether key management is needed at all, but whether the role you grant should be able to create, lifecycle-manage, or broadly administer long-lived service account keys. For least privilege, separate routine administration from key creation, use dedicated short-lived workflows where possible, and reserve the broader role only for the narrow cases that truly need it.

A common mistake is to treat “can manage keys” as a harmless convenience permission. In practice, key administration can expand blast radius because anyone who can mint or retain a durable credential can turn a maintenance task into persistent access.

When the workload can authenticate without static keys, that is usually the cleaner control point. Cloud Workload Identity Guide is the better mental model here because it frames keyless authentication as the default design goal, not an optional hardening step.

What to use instead of the Google Cloud Service Account Key Admin role

Use a narrower custom role or smaller predefined role that only covers the exact key operations you still need, such as listing or deleting keys where justified. If the real requirement is runtime access for a workload, move to workload identity, federation, or another short-lived credential path rather than giving humans or automation the ability to create reusable keys.

That distinction matters because key creation and key governance are different functions. A role that can rotate, disable, or inspect keys is not automatically appropriate for creating new long-lived credentials, especially in environments that already support keyless patterns. Google Cloud IAM and Service Accounts Guide covers the role and policy patterns that help separate those duties cleanly.

If you are reviewing an existing design, ask whether the principal actually needs key admin rights or just service account access. In many cases, the right answer is to grant service account impersonation or a workload identity flow, which preserves functionality without expanding the set of principals that can create durable credentials.

How least privilege changes the operational and security posture

Replacing the broad admin role changes both day-to-day administration and incident response. It reduces the number of identities that can create or preserve long-lived credentials, which lowers exposure if a human account, CI system, or support workflow is compromised. It also makes key creation an explicit event that can be logged, reviewed, and justified.

That matters because service account keys are an identity-bearing secret with a long shelf life. Ultimate Guide to NHIs is relevant here because it treats service accounts and keys as lifecycle-managed access material, not just configuration artifacts.

If you still allow key creation in any form, the next control is visibility. Alert on new key creation, unusual key age, and principals that have key permissions but rarely use them. NHI Lifecycle Management Guide is useful because key lifecycle and offboarding are the failure points that most often turn a narrow exception into standing risk.

Risk and Threat Considerations

Broad key administration increases the chance that a single compromised account can create durable access that outlives the original session or approval. The threat is not only theft of an existing key, but abuse of the permission to mint a fresh one after controls have been reset elsewhere.

Failure mechanism: A principal with key admin rights can generate, retain, or restore long-lived credentials that bypass the intended short-lived access model, which creates persistence even when interactive access is revoked.

Impact: Compromise becomes harder to contain because the attacker can maintain access through a credential that is easy to copy, difficult to detect quickly, and often reused by automation.

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, NIST Zero Trust (SP 800-207) 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-5 — Authenticator Management	Covers lifecycle control of service account keys and other authenticators.
Recommendation — Limit key creation, rotation, and revocation to authorized administrators.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	Supports replacing standing key trust with short-lived, verified access.
Recommendation — Use continuous verification and least privilege instead of durable key trust.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Long-lived service account keys are secrets that should not be broadly created or retained.
	NHI-07 — Long-Lived Secrets	The question is specifically about avoiding broad management of durable service account keys.
Recommendation — Reduce key creation paths and monitor for leaked or unnecessary credentials. Prefer short-lived credentials and eliminate long-lived keys where possible.
CIS Controls v8	CIS-5 — Account Management	Least-privilege account governance includes restricting who can administer service account keys.
Recommendation — Restrict privileged account capabilities to the minimum required administrators.

Practitioner Guidance

What to verify: Confirm whether any human, CI pipeline, or support function truly needs the ability to create new service account keys, or whether it only needs to use the service account at runtime. If the answer is runtime only, remove key admin rights and shift the workflow to keyless authentication or impersonation.

Decision rule: If a principal can create a long-lived credential, treat that capability as privileged access, not routine administration. If the work can be completed without key creation, do not leave the role in place “for convenience.”

Practitioner takeaway: Least privilege here means shrinking who can mint durable credentials, not merely renaming the permission set. The safest design is the one that makes key creation exceptional, reviewable, and unnecessary for normal workload operation.