Container Runtime Security
Falco, Tetragon, Tracee, eBPF-based detection - catch what supply-chain checks and admission policies miss, at runtime
Container Runtime Security
Runtime security watches what your workloads actually do once running. Supply-chain checks (Supply Chain Security) verify what you ship; admission policies (Policy as Code) gate what gets deployed. Runtime security catches what neither of those can — the live behavior of a container, a process, a syscall, a network connection.
The technology behind modern runtime security is eBPF — Linux's in-kernel programmable observability. Falco, Tetragon, Tracee, Sysdig, Aqua, and others use eBPF to see every syscall, every network connection, every file access, with minimal overhead, without modifying the kernel.
This is the layer that catches: a compromised dependency reading /etc/passwd, a process spawning /bin/sh from a web server, an attacker exfiltrating data over DNS, lateral movement attempts inside a cluster.
Why Runtime Security
| Layer | What it catches | What it misses |
|---|---|---|
| Supply chain (signing, SBOM, scanning) | Known CVEs at build; unsigned artifacts | Zero-days; runtime exploitation |
| Admission policy (Gatekeeper, Kyverno) | Bad configurations | Compromise after admission |
| Network policies | Disallowed network paths | In-process compromises |
| WAF / API gateway | L7 attacks at the edge | Internal lateral movement |
| Runtime security | Anomalous behavior in running containers | Things that look normal |
No single layer is enough. Runtime security is the "last mile" — the layer that fires when an attacker is already inside, doing something unexpected.
What Runtime Security Sees
eBPF programs hook into the kernel and observe events:
| Source | Examples |
|---|---|
| Process exec | bash was started inside a web container |
| File access | /etc/shadow was opened |
| Network connections | New egress to evil.com:443 |
| Mount operations | Host filesystem mounted into a pod |
| Privilege escalation | setuid or cap_set calls |
| Syscalls | ptrace, keyctl, unshare, kernel module load |
| DNS queries | Lookups to suspicious domains |
| Container lifecycle | New container started; exec into a container |
Each event is correlated to the workload (pod, container, image, namespace, labels) so a single line of alert tells you "checkout-pod (image checkout:v1.2.3) launched bash and connected to 1.2.3.4:443."
The Players
eBPF-based runtime detection
| Tool | License | Strengths |
|---|---|---|
| Falco | OSS (CNCF graduated) | The standard; rule-based; broad event support |
| Tetragon (Isovalent / Cilium) | OSS | Strong K8s context; tighter Cilium integration; supports prevention via overrides |
| Tracee (Aqua) | OSS | Strong analytics; behavioral signatures |
| Sysdig Secure | Commercial | Built on Falco; enterprise features; cloud integrations |
| Aqua | Commercial | Full stack: supply chain + runtime + cloud |
| Wiz Runtime Sensor | Commercial | CNAPP integration; agentless options |
| CrowdStrike Falcon | Commercial | EDR origin; container support |
Adjacent / related
| Tool | Purpose |
|---|---|
| Cilium | eBPF-based networking + security; mesh-like features |
| Pixie | eBPF observability; same tech, different focus |
| KubeArmor | LSM/eBPF-based runtime; can enforce, not just detect |
| Apparmor / SELinux | Mandatory access controls; classical Linux |
| gVisor | Userspace kernel; sandboxes containers |
| Kata Containers | Lightweight VMs per container; stronger isolation |
For most K8s teams: Falco (CNCF graduated, broad community, free) is the default. Tetragon is the modern eBPF-first alternative with prevention. Sysdig / Aqua for enterprises wanting a managed UI and integrations.
Detection Categories
A typical ruleset catches:
| Category | Example detections |
|---|---|
| Container escape attempts | Mount of /proc, host filesystem write, cap_sys_admin use |
| Suspicious processes | Shell spawned in production container, curl/wget in non-tooling image, nc listener |
| Reverse shells | TCP connect-back, dup2 stdio patterns |
| Credential access | Read of /etc/shadow, ~/.aws/credentials, K8s service account token |
| Cluster reconnaissance | Calls to kubernetes.default.svc from unexpected pods, kubectl exec in production |
| Crypto mining | High CPU + DNS to known mining pools + specific binary names |
| Data exfiltration | Large egress to unknown IPs, DNS tunneling patterns |
| Persistence | Write to /etc/cron.d, modification of binaries, package install at runtime |
Each category has many specific rules. Out-of-the-box rulesets cover MITRE ATT&CK for Containers reasonably well.
What Runtime Security Doesn't Do
Honest scope:
- Doesn't block by default (Falco) — it detects and alerts. Prevention is a separate concern (Tetragon, KubeArmor, Cilium TC override).
- Doesn't replace network policies — you still need Service Mesh / network policy for traffic restrictions.
- Doesn't fix application bugs — it sees the symptom, not the cause.
- Doesn't see encrypted contents — TLS traffic shows endpoints, not bodies.
- Has false positives — out-of-the-box rules need tuning to your workload.
The value is timely visibility into a small, suspicious set of events that you can act on.
Learning Path
1. Getting Started
Install Falco on kind; trigger a sample alert; explore the rule language; try Tetragon's K8s-aware detection
2. Patterns
Rule tuning, SIEM integration, MITRE ATT&CK mapping, blocking with Tetragon, anomaly detection, multi-cluster
3. Best Practices
Alert fatigue management, response runbooks, compliance, performance, common pitfalls, scaling
Compliance Drivers
Runtime security is increasingly required:
- PCI DSS 4.0: requires runtime threat detection in cardholder data environments
- SOC 2 CC7.2 (system monitoring): runtime detection evidences ongoing monitoring
- HIPAA: audit controls including unauthorized access detection
- NIST 800-53 SI-4: information system monitoring
Beyond compliance, it's a practical answer to: "we found this CVE; were we exploited before we patched?" Without runtime audit data, the only answer is "we don't know."
Runtime security is the layer that earns its keep on a bad day. Most days it's mostly quiet — a few false positives, some informational events. The day something bad happens, it's the only system that can tell you what the attacker did, when, and to what. Treat it as forensic infrastructure, not just preventive control. Tune it so the bad-day signal isn't drowned in good-day noise.