Kernel events & enrichment

The syscalls that matter, plus container context.

Detection starts with knowing which events matter and where they come from. Runtime security tools watch a small set of high-signal kernel events; understanding them tells you what your rules can and cannot see.

The events that matter

Most meaningful actions surface as syscalls: process execution (execve), file access (open, openat), network connections (connect, accept), privilege changes (setuid, capset), and namespace/mount operations (unshare, mount). A runtime tool captures these at the kernel, enriches them with context — which container, which pod, which image, which user — and evaluates rules against the enriched stream. The enrichment is what turns a raw "execve of /bin/bash" into "an interactive shell in the payments-api container", which is the difference between noise and a real alert.

# A raw syscall becomes a contextual security event:
#
#   execve("/bin/bash")                      ← kernel event
#   + container.id = 9f2c...                  ← runtime enrichment
#   + k8s.pod = payments-api-7c9,  ns = prod
#   + image = registry/payments@sha256:...
#   + user = root,  parent = sh
#   ⇒ rule: "shell spawned in a container" → ALERT (Warning)
#
# On a node you can watch exec events live with a tracer:
#   bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s\n", comm); }'

Context is the signal

The same syscall is benign or malicious entirely depending on context: a shell in a debug pod is normal; a shell in a production API container is a hands-on-keyboard indicator. Good runtime detection leans on the Kubernetes and container metadata to scope rules tightly — this image, this namespace, this expected process tree — so alerts fire on deviation from a known-good baseline rather than on the raw event. That scoping is also what keeps the alert volume low enough to be trusted.