Kernel-level workload identity: what it changes for IAM teams

TL;DR: SPIFFE deployments still rely on app libraries, sidecars, or proxies that add complexity, weaken process binding, and make workload identity harder to operate at scale, according to Riptides. Moving enforcement into the Linux kernel reframes NHI as a native control plane issue, not an add-on plumbing layer.

NHIMG editorial — based on content published by Riptides: Kernel Rethinking Workload Identity at the Kernel Level

By the numbers:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 69% of organisations now have more machine identities than human ones.
• Only 5.7% of organisations have full visibility into their service accounts.

Questions worth separating out

Q: How should security teams evaluate kernel-level workload identity for production use?

A: They should test whether the design improves process binding, removes helper-layer trust, and enforces identity at connection time across the environments they actually run.

Q: Why do sidecars and proxies create workload identity governance risk?

A: They create an extra identity layer between the workload and the communication event, which can weaken process fidelity and make troubleshooting or policy verification harder.

Q: When is SPIFFE alone not enough for NHI governance?

A: SPIFFE alone is not enough when identity is issued correctly but enforced inconsistently, or when secrets and policy still depend on helper processes.

Practitioner guidance

• Map identity enforcement to the runtime boundary Inventory where workload identity is actually enforced today, then separate policy definition from runtime enforcement.
• Test process binding explicitly Validate whether certificates and trust material are attached to the executing process or merely to the surrounding workload envelope.
• Reduce dependency on helper-layer identity Treat proxies and sidecars as transitional controls unless they are the only feasible path.

What's in the full article

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

• Kernel module packaging and compatibility work across Linux distributions and cloud provider ecosystems
• Implementation details for kTLS-based identity injection at the record layer
• Observability and tracepoint design used to debug kernel-level identity enforcement
• Installation and upgrade behaviour across existing provisioning workflows

👉 Read Riptides' analysis of kernel-level workload identity for SPIFFE environments →

Kernel-level workload identity: what it changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →