← News
/PLAYBOOK · 2026-08-20

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

Prerequisites

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

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.