Falco Container Runtime Security Hands-On: Real-Time K8s Anomaly Detection Config
Falco watches syscalls to flag anomalous behavior in containers and Kubernetes in real time: shells inside containers, reverse connects, sensitive-file reads. Full Helm deploy, rule authoring, and verification steps.
Falco container runtime detection is syscall-based. It flags anomalous behavior in containers and Kubernetes in real time: shells inside containers, reverse connects, sensitive-file reads. Core runtime security tool for cloud-native. This article covers deploy, rule config, and verification.
Use Cases
- Runtime security monitoring for Kubernetes clusters and Docker containers
- Detect container-escape precursors, reverse shells, privileged-container abuse
- Meet MLPS 2.0 and PCI-DSS runtime behavior-audit requirements
Prerequisites
- Linux kernel 3.10+ (eBPF driver needs 4.15+)
- Kubernetes 1.19+ cluster, or Docker-only
- Helm 3 (when installing via Chart)
How It Works
Falco captures syscall events via a kernel module (kmod) or eBPF probe, matches the event stream against a rules engine, emits alerts. Rules are macros, lists, and rules. Example: `container.id != host` tests whether the event is inside a container. Output: stdout, file, syslog, HTTP webhook. Wire to any alerting platform.
Procedure
1. Helm install (recommended)
`helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco --namespace falco --create-namespace --set driver.kind=ebpf --set falco.jsonOutput=true --set falco.fileOutput.enabled=true --set falco.fileOutput.filename=/var/log/falco_events.json`
2. Run directly on Docker
`docker run -it --rm --privileged -v /var/run/docker.sock:/host/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /etc:/host/etc:ro falcosecurity/falco:latest`
3. Custom rules /etc/falco/falco_rules_local.yaml
`- rule: Shell inside container
desc: Interactive shell executed inside a container (exclude known ops containers)
condition: >
spawned_process and container and shell_procs
and proc.aname not in (shell_binaries) and not user_known_shell_procs
output: Shell found inside container (user=%user.name shell=%proc.name cmdline=%proc.cmdline)
priority: WARNING
tags: [container, shell]`
4. Validate rule syntax
`falco --dry-run -r /etc/falco/falco_rules_local.yaml`
dry-run loads rules and checks syntax; does not start monitoring.
5. Trigger verification
`kubectl exec -it <pod-name> -- /bin/sh
# Inside the container: run whoami, cat /etc/shadow, and other sensitive operations, then exit`
Then check `/var/log/falco_events.json` (or kubectl logs) for a new WARNING record.
Verification
- `falco --dry-run -r ...` produces no syntax errors
- `helm status falco` is deployed; `kubectl logs -n falco deploy/falco` shows no driver-load errors
- After kubectl exec, the event file contains an alert with Shell found inside container
- Priority high to low: EMERGENCY > ALERT > CRITICAL > ERROR > WARNING > NOTICE > INFO > DEBUG; filter on that
FAQ
FAQ 1: kmod or eBPF?
Kernel 4.15+: prefer eBPF (`driver.kind=ebpf`). No compile, newer-kernel compatible. Older kernels: kmod. Install matching kernel headers first (`linux-headers-$(uname -r)`), or the driver fails to load.
FAQ 2: Too many false positives?
Do not edit the official falco_rules.yaml. Add falco_rules_local.yaml and override by same rule name, or drop priority, or append `and not user_known_xxx` macros to exclude known ops activity.
FAQ 3: How to fan out alerts to DingTalk or Slack?
Enable fileOutput, collect with filebeat or promtail. Lighter: enable programOutput and forward from a script, or deploy falcosidekick (native Slack, DingTalk, Webhook, S3).
Summary
Falco fills the gap image scanning and baseline checks miss: syscall-level behavior. Catches runtime attacks that look normal until they don't. Deploy the default ruleset plus a few custom rules. Persist events and forward to the alerting platform. Pair with Kube-bench baseline scans and Trivy image scans: scan, baseline, runtime.