Notifications
Clear all
Topic starter
11/06/2026 11:16 pm
TL;DR: Cryptographic signing, TLS orchestration, and just-in-time credential delivery require kernel-level control, making eBPF well suited to tracing and filtering packets but not to creating, binding, and protecting workload identities, according to Riptides. The deeper issue is that identity governance for non-human workloads breaks when the control plane cannot own the credential lifecycle end to end.
NHIMG editorial — based on content published by Riptides: When eBPF Isn’t Enough: Why We Went with a Kernel Module
Questions worth separating out
Q: When should security teams use kernel-level controls instead of eBPF for workload identity?
A: Use kernel-level controls when the job includes key creation, credential binding, protected delivery, or TLS orchestration.
Q: Why do short-lived workload credentials still need strong governance?
A: Short-lived credentials reduce exposure time, but they do not remove the need to govern bootstrapping, attribution, and revocation.
Q: What do security teams get wrong about eBPF and identity enforcement?
A: Teams often assume that because eBPF can inspect traffic, it can also handle identity operations.
Practitioner guidance
- Map which controls depend on packet visibility only Separate observability use cases from identity enforcement use cases.
- Audit every bootstrap secret in workload identity flows Identify where short-lived credentials still depend on a root secret or pre-existing token.
- Require process-scoped attribution for ephemeral credentials Make the issuing control prove which process requested the credential and when it was exposed.
What's in the full article
Riptides' full post covers the operational detail this post intentionally leaves for the source:
- Kernel crypto API limitations for asymmetric key generation and CSR handling
- Step-by-step explanation of TLS handshake orchestration inside the kernel module
- Detailed examples of header rewriting and on-the-wire credential injection logic
- eBPF attach-point comparisons such as XDP, SK_SKB, SK_MSG, and UPROBES
👉 Read Riptides' analysis of kernel modules versus eBPF for workload identity →
eBPF versus kernel modules for workload identity control?
Explore further
12/06/2026 7:53 am
Process-bound identity is the control boundary, not packet inspection. The article shows that workload identity fails as a governance problem when the tooling only sees traffic and not the execution context that owns the credential. Packet controls can filter or observe, but they do not establish who the identity belongs to or when it should exist. For IAM and NHI teams, the implication is that identity enforcement for workloads must be anchored to process lifecycle, not to network telemetry alone.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: How should organisations reduce secrets exposure in workload identity flows?
A: Push credential handling as close to the execution boundary as possible, and make exposure conditional on the requesting process. Minimise long-lived bootstrap material, eliminate unnecessary user-space handling of secrets, and ensure every delivery path has a clear owner. The goal is to make credential exposure both time-bound and attributable.
👉 Read our full editorial: Kernel-level identity beats eBPF for workload credential control
