Runtime Detection with eBPF: What Kernel-Level Telemetry Adds to Container Security

Container isolation is a set of kernel features, not a boundary the container runtime can fully police from inside itself. Detection that observes system calls at the kernel level sees process execution, file access and network connections regardless of what runs inside the container, which is why eBPF-based tooling has become a common runtime detection layer.

Why kernel-level observation changes the picture

A container shares the host kernel. A process inside it makes the same system calls as a host process, and an agent running inside the container is subject to the same isolation that an attacker can subvert. Telemetry collected in the kernel, or in a privileged enforcement component attached to it, is not reachable by a process that escapes its container constraints.
eBPF programs attach to kernel hooks and are verified before they load, which is what makes the approach practical without a kernel module per use case. The verification step is also the source of the constraint: a program is limited in what it can do and must pass the verifier to run at all.

What the telemetry supports

The useful detections group into a few behaviours that hold across implementations.

• Process execution from a path that a container image never contained, which is the signature of a dropped binary.
• A container process writing an executable file and then executing it, which is common in loader behaviour.
• Connections to destinations outside the expected egress set for that workload.
• Access to sensitive host paths from a container that should not mount them.
• Privilege changes within a container, particularly the acquisition of capabilities it was not granted. A practical starting point is to define the expected behaviour for a workload and alert on deviation, rather than attempting to enumerate malicious patterns. The enumeration approach produces a rule set that ages badly.

Deployment considerations

• Coverage depends on the kernel version and the distribution, and features differ across both. Confirm support on the oldest node in the fleet before assuming uniform capability.
• The agent must run with sufficient privilege to attach programs, which is a significant trust decision and should be scoped to the nodes it must cover.
• Volume is the practical constraint. Raw system call streams are enormous, and effective deployments filter in the kernel and enrich after collection rather than shipping everything.
• Kernel upgrades can invalidate assumptions about available hooks, so the detection stack belongs in upgrade planning. Verification is straightforward on a live node: confirm the programs are attached and confirm events are produced by executing a known command rather than by reading a dashboard that may be stale.

Defensive implications

• Pair kernel telemetry with admission control so that a workload cannot be scheduled with the host access the detection is meant to catch.
• Treat an alert from runtime telemetry as an incident signal, and make sure the response path is defined before the first alert.
• Retain enough context to reconstruct what a process did, since a single event without its parent process is rarely actionable.
• Test detections against an authorised exercise, because an unattached program produces no events and no error in some configurations. Limits worth stating: kernel telemetry observes what a process does, not why. It does not prevent an action, and where the detection cannot see a namespace or a nested runtime it may miss activity entirely. Its value is in shortening the interval between compromise and response, which remains the measurable objective.

References

• eBPF project documentation. https://ebpf.io/what-is-ebpf/
• Tetragon documentation. https://tetragon.io/docs/
• Kubernetes documentation, Pod Security Standards. https://kubernetes.io/docs/concepts/security/pod-security-standards/