Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Kernel workload identity without secrets: are your controls ready?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9079
Topic starter  

TL;DR: Workload identity should replace static credentials with short-lived, runtime-issued identities anchored in the kernel, reducing exposure from logs, backups, vaults, and CI pipelines while aligning with SPIFFE’s trust model, according to Riptides. The governance shift is bigger than rotation: identity must be provable continuously, not merely stored safely.

NHIMG editorial — based on content published by Riptides: Kernel Workload Identity Without Secrets: a Blueprint for the Post-Credential Era

By the numbers:

  • 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

Questions worth separating out

Q: What breaks when workload identity still depends on static secrets?

A: Static secrets create a replayable trust object that can be copied into logs, pipelines, backups, and metadata stores.

Q: Why do workload identity programmes need runtime attestation?

A: Runtime attestation ties access to the actual execution context instead of to a token that can be moved or reused.

Q: How can teams reduce secret sprawl in cloud workloads?

A: Teams should remove default credential distribution paths, prohibit secrets in code and pipelines, and make every new workload prove identity at runtime.

Practitioner guidance

  • Map every secret persistence point Trace where workload credentials appear in logs, CI pipelines, backups, metadata services, code commits, and config files, then remove each nonessential copy before changing the issuance model.
  • Move first trust into runtime attestation Require a workload to prove its execution context before it receives access, so identity is bound to runtime state rather than a portable secret that can be replayed elsewhere.
  • Separate bootstrap from standing access Design the initial trust step so it cannot become the long-lived credential path, and verify that no service account or token remains as the permanent fallback after startup.

What's in the full article

Riptides' full article covers the operational detail this post intentionally leaves for the source:

  • How the kernel-level enforcement model is expected to bind identity to individual process instances
  • The article's full explanation of SPIFFE-aligned runtime trust and why sidecars are treated as a deployment compromise
  • Implementation framing for removing secrets from workload bootstrap and replacing them with ephemeral identity
  • The vendor's own architecture claims about process isolation and deployment simplicity

👉 Read Riptides' analysis of kernel workload identity without secrets →

Kernel workload identity without secrets: are your controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8508
 

Secrets-based workload identity is now an exposure management problem, not a credential management problem. Once credentials are replicated into CI systems, backups, logs, and metadata stores, the governance burden shifts from issuing access to chasing exposure surfaces. That is why static secret reduction matters more than cleaner vault operations. Practitioners should treat every stored secret as an eventual compromise path, not an administrative asset.

A few things that frame the scale:

  • 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
  • 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why exposure and revocation have to be treated as one control problem.

A question worth separating out:

Q: When should organisations prefer ephemeral identity over long-lived credentials?

A: Organisations should prefer ephemeral identity when the workload can authenticate itself at runtime and the business does not need a reusable secret to operate. If the access path can be re-established on demand, ephemeral identity lowers replay risk, reduces cleanup burden, and removes the assumption that a token must survive beyond the session.

👉 Read our full editorial: Kernel workload identity without secrets changes NHI governance



   
ReplyQuote
Share: