Runtime Security on EKS
Tetragon eBPF enforcement, Falco detection, and GuardDuty stacked on EKS so one layer kills processes in-kernel, one builds a queryable alert history, and one catches what the other two miss.
Image scanning says nothing about what a container does once it's running. The first shell-exec enforcement policy also blocked /etc/passwd, which killed every process in the container at startup, since musl libc calls getpwuid() on launch and that call opens /etc/passwd.
Three runtime layers stacked on the same EKS cluster: Tetragon eBPF kprobes with a Sigkill action that kills a violating process inside the kernel before the syscall returns, Falco detecting the same events independently and forwarding structured alerts to CloudWatch via Fluent Bit and IRSA, and GuardDuty Runtime Monitoring correlating execve-level events against AWS threat intelligence.
Detection is not prevention. Tetragon's guarantee is that the process never gets control back.
Tetragon killed every /etc/shadow read and shell spawn with SIGKILL inside the kernel BPF hook, NENFORCE counters at 6 and 4, while nginx kept serving traffic at zero pod restarts throughout. GuardDuty separately surfaced a crypto-miner execution, a fileless-execution technique, and a service-account token read, none of which Tetragon's policies were written to catch.
- TracingPolicyNamespaced with Sigkill kills /etc/shadow reads and shell spawns in-kernel
- Falco correlates the same kernel event independently, forwarded to CloudWatch via Fluent Bit and IRSA
- GuardDuty catches what name-based exec blocking misses: busybox renamed to xmrig