Falco Runtime Container Security on Kubernetes: Step-by-Step 2026 Setup Guide

Container scanners tell you what is wrong with your image at build time. They do nothing once that image is running and an attacker is spawning shells inside it. Falco, the CNCF runtime security project, watches the Linux kernel through eBPF and alerts when a container does something it was never meant to do — running a shell, writing to /etc, connecting to an unexpected IP, or escalating privileges. In 2026 Falco 0.39 introduces a redesigned plugin system, native Prometheus metrics, and much better Kubernetes audit integration. This guide walks through deploying Falco on a production Kubernetes cluster, writing useful rules, and routing alerts.

## What Falco Actually Does

Falco loads a driver — either modern eBPF (the default in 2026), a kernel module, or classic BPF — that taps into Linux syscalls as they happen. It compares those syscalls against a rule set written in YAML and fires events when one matches. Because it operates at the syscall layer, it sees everything every container does, regardless of language, framework, or how the workload was deployed.

## Installing Falco with Helm

On a cluster running Kubernetes 1.28 or newer, Helm is the most practical path. Add the repo and install:

“`bash
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
kubectl create namespace falco
helm install falco falcosecurity/falco \
–namespace falco \
–set driver.kind=modern_ebpf \
–set tty=true \
–set falcosidekick.enabled=true \
–set falcosidekick.webui.enabled=true
“`

This deploys a Falco DaemonSet (one pod per node) and Falcosidekick, a small service that forwards events to Slack, Elasticsearch, Loki, or any webhook. Confirm pods are running:

“`bash
kubectl -n falco get pods
kubectl -n falco logs ds/falco | head -50
“`

You should see a line like `Falco version: 0.39.0` followed by the rules engine initializing.

## Verifying It Works

Trigger the well-known “shell spawned in container” rule:

“`bash
kubectl run alpine –image=alpine -it — sh
# inside the container:
cat /etc/shadow
“`

Within a second or two Falco logs a Warning event:

“`
Warning Sensitive file opened for reading by non-trusted program (user=root user_loginuid=-1 program=cat command=cat /etc/shadow file=/etc/shadow container_id=… image=alpine)
“`

If you see that, the pipeline works.

## Writing Custom Rules

Falco ships a strong default rule set, but every environment needs custom rules for its own indicators. Rules live in `falco_rules.local.yaml`. Here is one that alerts on any process making an outbound connection from a namespace that should only talk to the database:

“`yaml
– rule: Unexpected outbound connection from payments namespace
desc: Payments pods should only talk to the database on 5432
condition: >
evt.type = connect and evt.dir = < and k8s.ns.name = "payments" and not (fd.sip = "10.20.0.15" and fd.sport = 5432) output: >
Unexpected connection from payments (pod=%k8s.pod.name dst=%fd.sip:%fd.sport cmd=%proc.cmdline)
priority: WARNING
tags: [network, payments]
“`

Apply it by updating the chart values:

“`yaml
customRules:
payments.yaml: |-
– rule: Unexpected outbound connection…
“`

Then `helm upgrade falco falcosecurity/falco -f values.yaml`.

## Silencing False Positives

Package managers, CI runners, and some operators legitimately spawn shells. Silence them with `exception` clauses rather than disabling rules:

“`yaml
– rule: Terminal shell in container
exceptions:
– name: ci_runner
fields: [k8s.ns.name, container.image.repository]
values:
– [ci, gitlab/gitlab-runner]
“`

Exceptions are maintainable; rule deletions are not.

## Routing Alerts with Falcosidekick

Falcosidekick is the glue that turns Falco events into actionable notifications. Configure a Slack webhook and a PagerDuty integration in `values.yaml`:

“`yaml
falcosidekick:
config:
slack:
webhookurl: https://hooks.slack.com/services/XXX
minimumpriority: warning
pagerduty:
routingkey: abcd1234
minimumpriority: critical
“`

For long-term storage and correlation, forward to Loki:

“`yaml
loki:
hostport: http://loki.monitoring.svc:3100
minimumpriority: notice
“`

## Kubernetes Audit Log Integration

Falco can also consume the Kubernetes API audit log, catching things like a token being used to create a privileged pod. Enable it by pointing the API server at Falco’s webhook:

“`yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
– level: RequestResponse
resources:
– group: “”
resources: [“pods”, “secrets”]
“`

The `kubernetes` plugin in Falco 0.39 consumes this feed and applies rules like “user X created a pod with hostPID=true”.

## Prometheus Metrics

Falco 0.39 exposes native Prometheus metrics on port 8765:

“`yaml
metrics:
enabled: true
interval: 30s
output_rule: true
“`

Scrape with a ServiceMonitor and alert on event rate spikes:

“`yaml
– alert: FalcoCriticalEventsSpike
expr: increase(falco_events_total{priority=”Critical”}[5m]) > 5
“`

## Performance Impact

With modern eBPF, expect roughly 2–4% CPU overhead per node under normal workloads. On syscall-heavy applications (databases, proxies) you can see 6–8%. Tune by excluding high-volume innocuous syscalls in `falco.yaml`:

“`yaml
base_syscalls:
custom_set: []
repair: true
“`

## Falco and Compliance

Falco satisfies runtime detection requirements in PCI DSS 11.5.1, SOC 2 CC7.2, and HIPAA audit logging. Export events to your SIEM and retain for a year to produce audit evidence.

## FAQ

**Do I need to install anything on worker nodes manually?** No. The DaemonSet loads the eBPF probe at pod start. On older kernels without eBPF support you can fall back to the kernel module.

**Does Falco work on managed Kubernetes like EKS, GKE, and AKS?** Yes on all three. GKE requires enabling the eBPF driver because the kernel module is blocked on COS.

**Can Falco block actions, or just alert?** Falco is detective, not preventive. Combine it with an admission controller like Kyverno for prevention and Falco Talon for automated response.

**Does Falco replace image scanning?** No — use it alongside Trivy or Grype. Scanning catches known CVEs at build; Falco catches behavior at runtime.

**How much storage do I need for Falco events?** Plan for about 500 MB per node per day at default verbosity, much less if you tune out noise.

**Can Falco run outside Kubernetes?** Yes. The agent installs natively on Linux hosts via deb/rpm packages and protects bare-metal or VM workloads. The same rule syntax applies and Falcosidekick still routes events anywhere you want.

**Does Falco support Windows containers?** Not yet. Falco depends on Linux syscalls; Windows runtime security is still the domain of commercial EDR products.

**What is the difference between Falco and Tetragon?** Both observe kernel events with eBPF. Tetragon, from Isovalent, can also enforce — block syscalls inline rather than just alerting. Falco is detection-first and broader in rule ecosystem; Tetragon is enforcement-first and tightly coupled to Cilium.

## Threat Hunting With Falco

Beyond alerts, the events Falco generates form a powerful threat hunting corpus. Ship them into Loki, Elasticsearch, or a SIEM and you can ask questions like “show me every container that ran `curl` against an external IP in the past 30 days” or “list every shell spawn event in the production namespace this week.” Combined with MITRE ATT&CK tagging in the default rule set, the dataset maps cleanly to a structured hunting program.

## Falco Talon for Automated Response

Falco itself only alerts. Falco Talon, a 2024 addition, listens for Falco events and runs response actions: kill the offending pod, label it for quarantine, drop a network policy in front of it, or page a human. A typical Talon rule:

“`yaml
– name: kill_shell_in_payments
match:
rules: [Terminal shell in container]
output_fields:
k8s.ns.name: payments
action:
name: kubernetes:terminate
“`

This turns Falco from passive monitor into a closed-loop response system. Tune carefully — automated termination of misbehaving pods is powerful but can cascade if a rule misfires.

## Tuning Performance Further

For high syscall environments such as proxies and busy databases, the default rule set can chew through CPU. Use eBPF buffer settings to filter at the kernel level rather than user space:

“`yaml
syscall_event_drops:
threshold: 0.1
actions:
– log
– alert
rate: 0.03333
max_burst: 10
“`

The `base_syscalls.repair: true` option in 0.39 automatically adds the syscalls each loaded rule needs and excludes everything else, dramatically reducing event volume. If a node still struggles, profile with `falco –help-rules` to find the most expensive rules and override their conditions to be more specific.

## Multi-Cluster Falco

For organizations running many clusters, Falcosidekick can forward events to a central aggregator (Falco Sidekick UI, or directly to Loki/Elastic) and de-duplicate by cluster label. Add a cluster identifier in `customfields`:

“`yaml
falcosidekick:
config:
customfields: “cluster:prod-eu-west-1,env:production”
“`

This makes downstream filtering and dashboarding straightforward — alerts are tagged with origin without per-cluster duplicate dashboards.

## Integration with Admission Control

Pair Falco with an admission controller like Kyverno or OPA Gatekeeper for defense in depth. Admission controllers prevent insecure pods from being created in the first place (no privileged containers, no hostPath, no run as root); Falco catches anything that slips through and runs at the kernel level. Together they cover both prevention and detection — neither alone is sufficient for a serious security posture in 2026.

## Compliance Mapping

Falco’s default rule set is mapped to PCI DSS 4.0, NIST 800-53, MITRE ATT&CK, and SOC 2 control families. Export the mapping table from `/etc/falco/falco_rules.yaml` and present it to auditors as evidence of runtime monitoring coverage. For HIPAA, the file integrity events from Falco satisfy the integrity safeguard at 164.312(c). Each rule’s `tags` field includes the relevant frameworks, making compliance reports a simple grep away.

## Upgrading Falco Safely

Like any kernel-adjacent component, upgrade Falco in a staged manner. Roll the new version out to a non-production cluster first, run for at least a week, watch for unexpected event volume changes or rule regressions, then promote to production node by node using the DaemonSet update strategy. Pin the chart and image versions in your Helm values rather than tracking `latest` — predictable upgrades are far less stressful than surprise ones, especially when the eBPF probe interacts with kernel features that may differ between minor version bumps.

## Lessons From Real Incidents

Teams that have used Falco through a real incident converge on the same lessons. First, default rule output is too noisy to alert on directly; route everything to a log store and alert on a curated subset. Second, the highest-value custom rules are environment-specific — outbound connections from namespaces that should never talk to the internet, writes to read-only application directories, and unexpected binaries executing inside production images. Third, the speed of triage matters more than detection coverage; build a runbook that pivots from a Falco event to the responsible pod, the container image, and the recent changes in seconds. Fourth, retain at least 90 days of events because forensic analysis often runs weeks after the original event. With these four practices, Falco shifts from a noisy demo into a real detection engine that catches things image scanning never could.