Kernel telemetry and workload identity: what observability gaps remain?

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

View Full Forum →  |  NHI Foundation Course →