Secretless GCP workload identity exposes the limits of static keys

At a glance

What this is: This post argues that GCP workloads can be run without stored secrets by combining SPIFFE identity, Workload Identity Federation, and runtime credential injection.

Why it matters: It matters because IAM and platform teams must now govern machine and AI-workload access without relying on downloadable keys, shared tokens, or manual rotation.

By the numbers:

• Only 38% have automated certificate lifecycle management in place.
• 69% of organisations now have more machine identities than human ones.
• 61% rely on spreadsheets or manual tracking for machine identity management.

👉 Read Riptides' full walkthrough of secretless GCP workload identity

Context

Secretless workload identity is the practical response to a simple governance problem: static keys are easy to issue and hard to control. In cloud and AI workflows, downloaded credential files, long-lived access tokens, and copied service account keys create persistence that IAM teams cannot reliably see, review, or revoke.

This post focuses on GCP because it makes the identity issue concrete. The question is not whether a workload can authenticate, but whether its authentication can be tied to a verifiable workload subject, short-lived issuance, and enforceable policy instead of secrets sitting in files, laptops, or pipelines. See the broader identity model in our Ultimate Guide to NHIs and the federation mechanics in the SPIFFE workload identity specification.

Key questions

Q: How should security teams replace static service account keys in cloud workloads?

A: Start by binding each workload to a verifiable identity and exchanging that identity for short-lived cloud credentials at runtime. The workload should never need to store a reusable key file, and the cloud role should be limited to the exact service the workload must call. That shifts control from secret handling to subject-based trust.

Q: Why do static credentials create more risk than runtime-issued workload identity?

A: Static credentials persist after the decision to trust them, so they can be copied, reused, and forgotten across laptops, repos, and pipelines. Runtime-issued workload identity narrows the access window, improves auditability, and makes revocation meaningful because the credential is tied to a specific workload subject and moment of use.

Q: What do IAM teams get wrong about secret rotation for machine identities?

A: They often treat rotation as the main control when the larger issue is credential portability. If the same secret can be reused across services or environments, rotation only shortens exposure after the fact. The better control is to stop issuing portable secrets where a workload-bound identity will do the job.

Q: Which frameworks should teams use for workload identity federation and zero trust?

A: For cloud workload access, map the design to SPIFFE concepts, the OWASP Non-Human Identity Top 10, and zero trust controls that assume credentials are untrusted until proven in context. Those references help teams evaluate subject binding, token exchange, and least-privilege enforcement without falling back to static keys.

Technical breakdown

Static GCP service account keys and secret sprawl

Downloaded service account keys and access tokens are classic non-human identity artifacts, but they behave like durable credentials rather than runtime proofs. Once copied into .env files, CI jobs, laptops, or repos, they become difficult to inventory and nearly impossible to bound by session or purpose. The real technical weakness is not just storage. It is that the credential outlives the workload context that justified it, so authentication and authorisation drift apart over time.

Practical implication: replace file-based key distribution with workload-bound credential issuance and remove durable secrets from application paths.

SPIFFE federation into cloud provider trust

SPIFFE gives a workload a cryptographically verifiable identity that can be exchanged into a cloud-understandable token through federation. In this pattern, the workload subject, not the static secret, becomes the unit of trust. GCP workload identity federation then maps that subject to a service account or direct resource access policy. This is what allows short-lived credentials to be minted on demand without the application handling the sensitive material directly.

Practical implication: define the workload subject and trust mapping first, then only grant the cloud-side role needed for that subject.

Kernel-layer credential injection and runtime enforcement

Kernel-layer enforcement changes the control point from application logic to the operating system boundary. Instead of teaching each app how to fetch, store, and refresh secrets, the platform injects ephemeral credential material at connection time for the authorised workload only. That reduces duplication, prevents secret reuse across services, and makes access more auditable because the credential exists only while the protected action is happening. It also narrows the failure domain when a workload is compromised.

Practical implication: centralise credential delivery at the runtime boundary so access can be scoped per workload and per connection.

Threat narrative

Attacker objective: The attacker wants durable access to cloud APIs and the ability to act as a trusted workload without triggering normal identity review or rotation controls.

1. Entry occurs when a long-lived service account key, access token, or credential file is copied into an application environment and reused across systems.
2. Credential abuse follows when that static material authorises multiple calls until it is manually rotated or revoked, creating a standing access window.
3. Impact is persistent cloud access with weak provenance, larger blast radius, and poor forensic attribution because the secret represents the workload rather than proving it.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static credential governance was designed for access that stays visible long enough to be reviewed. That assumption fails when cloud workloads are issued short-lived, runtime-scoped credentials instead of durable secrets. The implication is that identity governance has to measure where access is created and destroyed, not where files are stored.

Secretless workload identity is not an optimisation, it is an answer to credential lifecycle failure. Once a service account key is downloadable, copied, and reused, the control model depends on human discipline to recover the lost boundary. That is why workload identity must be treated as the primary trust primitive for cloud-native machine access. Practitioners should stop treating key rotation as the core control and start treating secret elimination as the baseline.

Kernel-enforced identity narrows the identity blast radius in ways application-layer auth cannot. When the runtime boundary issues credentials only to the authenticated workload, the credential no longer behaves like a portable asset. This changes how we think about auditability, because provenance becomes bound to process and connection rather than to a shared file path. For IAM teams, that means platform enforcement now belongs in the identity model, not just the infrastructure stack.

Workload Identity Federation is the bridge, but the governance decision remains the same. Federation solves interoperability with cloud providers, yet it does not justify keeping static keys around as a fallback habit. The category is moving toward subject-based trust with ephemeral exchange, and organisations that still depend on download-and-store patterns will carry unnecessary access debt. Practitioners should re-evaluate every service account flow that still begins with a key file.

Secretless design sharpens the distinction between authentication proof and authorisation policy. A verifiable workload subject can prove who or what is calling, but the cloud role still determines what that workload may do. That separation is healthy, but it also exposes over-granting faster because the identity itself is no longer the weak link. The practical conclusion is that entitlement review becomes more visible, not less, once secrets disappear.

From our research:

• Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
• A separate finding in the same report shows that 57% of organisations lack a complete inventory of their machine identities, which makes secret elimination harder to govern at scale.
• For teams moving from static keys to runtime identity, the broader control set is covered in Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

What this signals

Secretless authentication will force a governance reset around machine identity inventory. When credentials are issued at runtime, the critical control is no longer where a key file lives but whether every workload has a known subject and owner. That is why the organisations that still lack complete machine identity visibility will struggle most as more services move to federation and ephemeral credentials.

Identity blast radius becomes the operative metric. As service accounts stop relying on reusable secrets, teams can finally separate a workload's current authority from the historical residue of earlier grants. That makes privilege review more precise, especially when the credential path is tied to SPIFFE workload identity specification subjects rather than shared files.

Secretless design does not reduce the need for lifecycle governance, it raises the bar for it. More workloads, more subject mappings, and more federated exchanges mean more places where ownership, revocation, and entitlement scope must stay current. Our research shows 69% of organisations now have more machine identities than human ones, so the operational burden is already machine-led rather than human-led.

For practitioners

• Remove downloadable service account keys Eliminate JSON key files from application configuration and CI/CD paths. Replace them with runtime-issued workload credentials so the application never receives a reusable secret.
• Map each workload to a verifiable subject Assign a stable SPIFFE-style subject to every workload that needs cloud access, then bind that subject to the minimum cloud role required for the task.
• Shift cloud access to federation and impersonation Use Workload Identity Federation or equivalent subject exchange so the cloud trusts the workload identity, not a copied token or locally stored file.
• Move credential delivery to the runtime boundary Inject short-lived credentials at connection time or via OS-level identity controls instead of distributing secrets through environment files and application code.
• Review service account privilege drift Check whether service accounts used by workloads have accumulated roles beyond their original purpose and trim them before introducing secretless access patterns.

Key takeaways

• Static keys remain the core weak point in cloud workload identity because they outlive the context that created them.
• The evidence points to a scale problem, not just a tooling problem, with machine identities already outnumbering human ones in most organisations.
• Practitioners should move control away from secret handling and toward workload-bound federation, runtime issuance, and entitlement review.

Key terms

• Workload Identity Federation: A trust exchange that lets a workload prove its identity to one system and receive a credential understood by another. In practice, it removes the need to copy static secrets across environments and replaces them with short-lived, subject-bound tokens.
• SPIFFE Identity: A cryptographically verifiable identity for a workload, usually expressed as a SPIFFE URI. It gives the platform a stable subject to authorise, audit, and federate without relying on a secret file as proof of identity.
• Service Account Impersonation: A pattern where a workload receives permission to act as a cloud service account without possessing the account's long-lived key. It reduces secret exposure but still requires tight scope, clear subject mapping, and strong lifecycle control.
• Secretless Authentication: An access model where a workload authenticates and receives credentials at runtime instead of storing reusable secrets. The security value comes from narrowing credential lifetime, reducing copy risk, and making identity proof more explicit at the moment of use.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.

This post draws on content published by Riptides: On demand credentials - Secretless AI assistant example on GCP. Read the original.