SPIFFE workload identity in the kernel: what changes for teams

TL;DR: SPIFFE defines workload identity cleanly, but SPIRE still leaves certificates, renewal, and enforcement too close to user space, creating a gap between identity issuance and real-time control, according to Riptides. That gap matters because identity governance for workloads is only as strong as the layer that can actually enforce it.

NHIMG editorial — based on content published by Riptides: Why Riptides Embraces SPIFFE But Not SPIRE

By the numbers:

• Only 38% have automated certificate lifecycle management in place.
• 69% of organisations now have more machine identities than human ones.

Questions worth separating out

Q: How should security teams govern workload identity when certificates are handled in user space?

A: Teams should treat user-space certificate handling as a control dependency, not a complete governance model.

Q: Why do service meshes and sidecars complicate workload identity governance?

A: They insert extra components between the workload and the control point, which increases operational complexity and can shift the certificate relationship from the process to the proxy.

Q: When does a workload identity standard stop being enough on its own?

A: A standard stops being enough when identity is defined clearly but enforcement depends on external components that teams cannot verify consistently.

Practitioner guidance

• Separate identity issuance from enforcement Map where workload identities are created, where certificates are loaded, and where policy is enforced.
• Reduce direct credential handling in applications Identify workloads that still request, store, or renew certificates in code or sidecars, then prioritise designs that remove direct handling from the application path.
• Test enforcement at the runtime boundary Validate whether policy decisions can be enforced at the workload boundary rather than only through proxy or mesh logic.

What's in the full article

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

• How the kernel-level identity flow is implemented across workload startup, certificate handling, and trust establishment
• The specific differences between user-space, proxy-based, and kernel-based enforcement paths
• How on-the-wire credential injection works for third-party services that do not speak SPIFFE
• The federation model used to extend workload identity across multiple cloud environments

👉 Read Riptides' analysis of SPIFFE versus SPIRE for kernel-based workload identity →

SPIFFE workload identity in the kernel: what changes for teams?

Explore further

View Full Forum →  |  NHI Foundation Course →