Falco on Kubernetes: Runtime Security with eBPF

Most Kubernetes security tools scan for misconfigurations — pods running as root, missing network policies, RBAC roles that are too permissive. Those checks matter, but they don't tell you what's actually happening at runtime.

Falco fills that gap. It runs as a DaemonSet and monitors kernel-level system calls from every container on your nodes using eBPF. When a process does something suspicious — spawns a shell inside a production pod, reads sensitive credential files, opens an outbound connection to an unexpected host — Falco fires an alert in real time.

What Runtime Security Actually Catches

The default Falco ruleset detects:

• Shells spawned inside containers from web app exploits or direct exec
• Privilege escalation attempts inside containers
• Sensitive file reads — /etc/shadow, SSH keys, cloud credential files
• Unexpected outbound traffic to mining pools or C2 servers

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \\
    --create-namespace \\
    --namespace falco \\
    --set driver.kind=modern_ebpf \\
    --set collectors.kubernetes.enabled=true \\
    --set falcosidekick.enabled=true

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \\
    --create-namespace \\
    --namespace falco \\
    --set driver.kind=modern_ebpf \\
    --set collectors.kubernetes.enabled=true \\
    --set falcosidekick.enabled=true

Three flags that matter:

driver.kind=modern_ebpf — CO-RE eBPF probe, no kernel headers needed, works on kernel 5.8+. Auto picks kmod on some configurations, so set this explicitly.

collectors.kubernetes.enabled=true — adds pod name, namespace, and deployment context to every alert. Without it, you get a process name and PID with no idea which service triggered it.

falcosidekick.enabled=true — deploys the alert routing service alongside Falco.

Alert Routing with Falcosidekick

Falcosidekick handles the routing to your notification systems. Configure integrations through Helm values:

helm upgrade falco falcosecurity/falco \\
    --namespace falco \\
    --set falcosidekick.enabled=true \\
    --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/YOUR/WEBHOOK/URL" \\
    --set falcosidekick.config.pagerduty.routingKey="YOUR_ROUTING_KEY"

helm upgrade falco falcosecurity/falco \\
    --namespace falco \\
    --set falcosidekick.enabled=true \\
    --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/YOUR/WEBHOOK/URL" \\
    --set falcosidekick.config.pagerduty.routingKey="YOUR_ROUTING_KEY"

The practical approach: route WARNING+ to Slack, CRITICAL and ERROR to PagerDuty. Tune for 48 hours before enabling PagerDuty — the default rules flag some legitimate startup behavior that needs filtering for your specific environment.

Customizing Rules

Custom rules go in falco_rules.local.yaml and load after defaults. You can override built-in rules or add new conditions specific to your workloads. The condition language uses Falco fields like proc.name, container.image.repository, and fd.sport — see the official Falco documentation for the complete field reference.

Full setup guide at devtoolhub.com/falco-kubernetes-runtime-security/

Originally published on DevToolHub: https://devtoolhub.com/falco-kubernetes-runtime-security/