Notifications
Clear all
Topic starter
12/06/2026 12:29 am
TL;DR: Kernel tracepoints can be carried through eBPF, OpenTelemetry, and Prometheus to turn raw file-creation events into labeled metrics, according to Riptides. But the deeper lesson is that kernel-level telemetry only helps if identity and workload posture are already governed, and the real gap is not visibility alone, but whether workloads have disciplined, reviewable identity boundaries.
NHIMG editorial — based on content published by Riptides: From Tracepoints to Prometheus, the journey of a kernel event to observability
Questions worth separating out
Q: How should security teams use kernel telemetry in workload identity programmes?
A: Use kernel telemetry as evidence, not as a control.
Q: Why does observability not replace workload access governance?
A: Observability tells you that an event happened.
Q: How do organisations know if telemetry is actually improving identity control?
A: Look for evidence that telemetry is driving decisions, not just dashboards.
Practitioner guidance
- Map kernel telemetry to workload identities Bind tracepoint output to a current inventory of service accounts, workloads, and owning teams so each metric can be traced back to an accountable identity.
- Validate the event path before operational use Test architecture-specific handling, kernel-version assumptions, and ring-buffer behaviour so the telemetry you depend on is stable across the environments you run.
- Separate observation from enforcement Use kernel metrics as evidence for review and detection, but keep authorization, lifecycle changes, and access decisions in governed identity controls such as policy and approvals.
What's in the full article
Riptides' full post covers the operational detail this post intentionally leaves for the source:
- Kernel module code and the exact kretprobe wiring used to detect file creation events
- Go loader and ring-buffer reader implementation details for moving samples into user space
- OpenTelemetry setup and Prometheus exporter code for turning events into counters and labels
- Build and test steps for running the demo in a Lima-based Linux VM
👉 Read Riptides' walkthrough of kernel tracepoints, eBPF, OTEL, and Prometheus →
eBPF telemetry for workloads: what IAM and NHI teams miss?
Explore further
12/06/2026 9:45 am
Kernel telemetry is becoming part of workload identity governance, not a separate discipline. The moment file creation, service posture, and inter-service communication are captured at kernel level, observability starts to overlap with machine identity control. That overlap matters because the same workload that emits telemetry is also the subject of access decisions, privilege scope, and lifecycle review. The implication is that identity and observability teams can no longer treat telemetry as downstream plumbing.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why runtime telemetry and identity inventory often diverge in practice.
A question worth separating out:
Q: What is the difference between workload monitoring and workload identity governance?
A: Workload monitoring measures activity. Workload identity governance defines who or what may act, for how long, and under what lifecycle conditions. A team can have excellent kernel telemetry and still lack control over service account sprawl, privilege scope, or offboarding. Governance is the decision layer; monitoring is the evidence layer.
👉 Read our full editorial: Kernel telemetry and eBPF tracing still expose workload identity gaps
