CoursesRuntime & eBPF securityFalco & runtime detection

Falco runtime detection

Driver, engine, rules; shells in containers.

Advanced35 min · lesson 7 of 15

Falco is the CNCF runtime detection engine that turns the kernel event stream into security alerts. Where an image scanner tells you a container might be vulnerable, Falco tells you a container is behaving maliciously right now — a shell spawned, a sensitive file written, an unexpected outbound connection.

Architecture: driver, engine, rules

Falco has three parts. A driver — the modern eBPF probe (or the legacy kernel module) — captures syscalls at the kernel and enriches them with container and Kubernetes context. The engine evaluates each event against a rule set. And the rules themselves are conditions over event fields, each with an output template and a priority. Deployed as a DaemonSet, Falco puts a detection agent on every node so it sees the syscalls of every workload scheduled there — a single central pod could never see other nodes’ kernels.

a Falco rule, macro, and list
# Reusable building blocks:
- list: shell_binaries
items: [bash, sh, zsh, ash, dash]
- macro: container
condition: container.id != host
# The rule: an interactive shell launched inside a running container.
- rule: Terminal shell in container
desc: A shell was spawned in a container — possible hands-on-keyboard intrusion
condition: spawned_process and container and proc.name in (shell_binaries)
output: "Shell in container (pod=%k8s.pod.name ns=%k8s.ns.name image=%container.image.repository proc=%proc.cmdline)"
priority: WARNING

What Falco is good at

Falco excels at behavioral detection that no static scan can provide: shells and unexpected binaries in containers, writes to sensitive paths (/etc, /root/.ssh), reads of secret files, privilege escalation, and suspicious outbound connections. Plugins extend the same engine beyond syscalls to sources like Kubernetes audit logs and cloud trails, giving one detection language across the kernel and the control plane. It is detection-only by default — it observes and alerts, and turning alerts into action is a deliberate next step (routing and response).

Falco pipeline
1eBPF driver
capture + enrich syscalls
2rule engine
evaluate conditions
3alert
output + priority
4route (sidekick)
to SIEM / response
Kernel events in, contextual alerts out, on every node via a DaemonSet. Detection-only by default — pair it with routing and response.
Detection without routing is a dead end
Falco writing alerts to a pod log that nobody ships anywhere changes nothing. Route its output (via Falcosidekick) into your SIEM and alerting from day one — an unmonitored detection engine gives false assurance while catching nothing you can act on.