Falco: Runtime Threat Detection with eBPF

Actualizado: 2026-05-03

Threat detection has lived through two eras: perimeter (firewalls, network IDS) and endpoint (EDR on laptops). Containers and Kubernetes break both assumptions — the perimeter is blurry, endpoints are ephemeral. Falco^[1], a graduated CNCF project, attacks the problem from a different angle: watch the kernel and alert when something does unexpected things. This guide covers what Falco does well, what it doesn’t do, and what it needs around it to be useful in production.

Key takeaways

• Falco hooks the Linux kernel via eBPF and observes syscalls in real time — without instrumenting applications.
• The modern eBPF driver (CO-RE, since Falco 0.34+) is portable across kernels and is the recommended choice for Debian 12+, Ubuntu 22.04+, and RHEL 9+.
• Falco is not antivirus or WAF: it is syscall anomaly detection that complements other security layers.
• Deploying without a response process is theatre: alerts without triage are noise, not defence.
• Falcosidekick routes events to Slack, PagerDuty, Loki, and dozens more destinations.

What Falco Watches

Falco hooks the Linux kernel (via eBPF or a traditional module) and observes syscalls in real time. Each syscall — open, execve, connect, setuid — passes through its rules. If one fires, Falco emits an event.

Default rule examples:

• Shell in container: an interactive shell opens inside a production container.
• Write to /etc: a process modifies sensitive system files.
• Binary executed from /tmp: classic malware dropper pattern.
• Unexpected outbound connection: the container calls an unknown IP.
• Privilege change: a process escalates to root without it being its usual CMD.

The power is in granularity: not “the container did something bad”, but “PID 1234 called execve with argv=/bin/sh inside this pod’s namespace, and that doesn’t match baseline”.

eBPF vs Kernel Module Architecture

Falco supports three drivers:

• Modern eBPF (CO-RE, since Falco 0.34+): portable across kernels, no compilation, no loaded module. The recommended one.
• Legacy eBPF: requires kernel headers at build time.
• Kernel module: oldest. Useful on very old kernels (<5.8) but increasingly irrelevant.

For Debian 12+, Ubuntu 22.04+, Amazon Linux 2023, and RHEL 9+, the modern eBPF driver works without fighting.

Rules: The 80/20

Falco ships with falco_rules.yaml and ~80 out-of-the-box rules. The reasonable path:

1. Start with defaults. See what noise your real environment generates in the first 2-3 days.
2. Silence common false positives. Your backup copying files to /etc/cron.d fires “write to sensitive path” — but is legitimate.
3. Add stack-specific rules, for example: “nobody runs kubectl exec outside office hours”.
4. Invest the rest in runbooks for real events.

Custom rule example:

- rule: AWS credentials access
  desc: Access to .aws directory or EC2 metadata
  condition: (fd.name in (~/.aws/credentials) or fd.name=169.254.169.254)
  output: "Possible AWS credential extraction (user=%user.name)"
  priority: WARNING

Output: SIEM and Notification

Falco emits JSON events. What you do with them defines the utility:

• Falcosidekick (official companion): event router to Slack, PagerDuty, Elasticsearch, Loki, Alertmanager, and dozens more.
• Loki + Grafana: events as logs, alerts via Grafana Alerting. Good for teams already on the stack.
• SIEM (Splunk, Sentinel, Elastic Security): Falco as one detection source among several.

The common error is leaving events in /var/log/falco.log and never looking. Without routing to a reviewed destination, Falco is local noise.

Deployment on Kubernetes

In Kubernetes, Falco runs as a DaemonSet — one pod per node with privileged access to the node’s kernel.

• Official Helm chart: falcosecurity/falco, with options for driver, rules, and event export.
• Requires privileged securityContext or hostPID + hostNetwork + specific capabilities. That’s risk surface — Falco has more privileges than almost anything else in the cluster.
• Resources: ~200 MB RAM, 0.1-0.5 CPU per node at rest. Spikes during mass pod starts.
• Frequent updates: threat rules change; keep Falco current.

Where Falco Falls Short

Being honest about limits:

• Memory-only attacks without observable syscalls fly under the radar.
• Malicious behaviour inside normal syscalls (exfil via normal HTTPS to a C2) requires destination-specific rules.
• Sophisticated cryptojacking can avoid obvious patterns.
• Kernel zero-days that subvert eBPF.

Falco is not antivirus or WAF. It is syscall anomaly detection. Complements other layers; doesn’t replace them.

Kubernetes Audit Integration

Beyond syscalls, Falco can consume the Kubernetes API audit log and apply rules over API actions. Useful for detecting:

• RBAC changes outside hours.
• Mass creation of privileged pods.
• Unusual Secrets access.

Operations: What Hurts

A year running Falco in production teaches clear lessons:

• Updating rules without versioning is chaotic. Keep rulesets in Git with CI validating them.
• Drift between Falco and kernel: each major kernel update can break eBPF CO-RE via edge cases.
• Alert fatigue: if 90% of alerts are benign, the important 10% is lost. Invest in refinement.
• Cost on dense nodes: 200 pods/node means many syscalls. Monitor Falco CPU.
• Team turnover: if nobody understands the rules, nobody refines them. Document.

When to Adopt Falco

Clearly useful:

• Kubernetes in production with third-party pods or multi-tenant environments.
• Compliance requiring runtime monitoring (PCI DSS, mature SOC 2).
• Teams with SOC able to triage events.

Marginal or overkill:

• A single Docker node. Falco is too much — a well-configured auditd is simpler.
• Teams without a response process. Alerts without response are theatre, not security.

Related: Falco pairs well with artifact signing via Sigstore — one protects the supply chain before deployment, the other detects anomalous behaviour at runtime. And if you use a service mesh with mTLS, both layers contribute to a more complete Zero Trust security model.

Conclusion

Falco is a mature, open-source piece for runtime detection in cloud-native environments. It requires investment in operation — tuned rules, event routing, response process — but in return offers visibility that traditional layers don’t reach. Before adopting, ask whether your team has the capacity to process its events; if not, prioritise that before deployment. Detecting without responding is noise; detecting with response is real defence.

1. Falco