Notifications
Clear all
Topic starter
24/06/2026 9:15 pm
TL;DR: Kernel-level workload identity enforcement needs telemetry beyond standard observability, because tracepoints, ring buffers, and user-space enrichment are required to validate policy and correlate behaviour in real time, according to Riptides. The practical lesson is that NHI controls are only as trustworthy as the telemetry layer that proves they are actually working.
NHIMG editorial — based on content published by Riptides: Kernel telemetry Linux kernel module telemetry: beyond the usual suspects
Questions worth separating out
Q: How should security teams instrument kernel-level workload identity enforcement?
A: Security teams should place telemetry at the enforcement layer, not only at the application layer, when workload identity is validated inside the Linux kernel.
Q: Why do workload identity programmes need kernel telemetry as well as OpenTelemetry?
A: Workload identity programmes need kernel telemetry because OpenTelemetry is strongest in user space, while many identity enforcement decisions happen lower in the stack.
Q: What breaks when identity telemetry is collected too far above the kernel?
A: When telemetry is too far above the kernel, teams lose visibility into the actual enforcement moment.
Practitioner guidance
- Map the enforcement boundary first Identify where workload identity decisions are actually enforced inside the kernel, then place telemetry hooks at that boundary instead of relying on downstream application logs.
- Separate capture from enrichment Keep the kernel payload minimal, move correlation and context-building into user space, and use a lockless transport so telemetry does not become a bottleneck.
- Validate policy outcomes with runtime evidence Use telemetry to confirm that workload identity policies are behaving as intended across hosts, services, and identity flows, not just in configuration review.
What's in the full article
Riptides' full article covers the operational detail this post intentionally leaves for the source:
- The tracepoint and ringbuf implementation pattern used to move events out of the kernel with low overhead
- The Go-based collector flow for loading eBPF programs and reading telemetry from the buffer
- The user-space aggregation, enrichment, and OTEL export path for Prometheus, Jaeger, and Zipkin
- The practical reasons the team chose custom kernel telemetry over generic profiling tools
👉 Read Riptides' analysis of kernel telemetry for workload identity enforcement →
Kernel telemetry and workload identity: what observability gaps remain?
Explore further
25/06/2026 6:21 am
Kernel-native identity enforcement creates a telemetry dependency, not just an observability preference. If policy is executed inside the kernel, the organisation must be able to prove what happened at that layer, not merely that an API call completed. That shifts telemetry from operations support to identity assurance, because the security control itself becomes unverified without it. Practitioners should treat kernel visibility as part of the enforcement model, not an afterthought.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly identity assurance breaks down when telemetry and ownership are weak.
A question worth separating out:
Q: How do teams know if telemetry is good enough for workload identity governance?
A: Telemetry is good enough when it can answer three questions consistently: what identity action occurred, where it was enforced, and what system behaviour followed. If those three signals cannot be correlated at runtime, the programme has observability, but not governance-grade evidence.
👉 Read our full editorial: Kernel telemetry for workload identity needs deeper observability
