Posts

Bridging the Kubernetes Exec Identity Gap: One Hook Was Never Enough

The second post concluded that eBPF is the only viable mechanism. This is the implementation. Five iterations, each surfacing a kernel constraint or a gap that forced the next design decision, ending in a two-hook architecture that resolves the request_id inline at execve and survives spoofing from inside the container.

Exploring the Kubernetes Exec Identity Gap: Why the Obvious Fixes Fail and What Actually Works

The previous post named the gap and sketched two fixes. Here: why the PID cannot exist when audit needs it, what SPO’s requestId env really buys you, and why eBPF is the remaining credible path before implementation.

The Kubernetes Exec Identity Gap: Kubernetes Cannot Tell You Who Ran That Command

Your audit log names who opened the exec session. Your runtime agent names the process. Nothing in the platform connects the two. You cannot know who ran a command inside that container.