Falco on Kubernetes: Runtime Security with eBPF

Originally published on DevToolHub.

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. A container could be perfectly configured and still execute a reverse shell the moment a vulnerability gets exploited.

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.

[IMAGE: articles/images/2026-07-05-falco-kubernetes-runtime-security-featured.png | alt: "falco kubernetes runtime security architecture with eBPF kernel monitoring"]

Falco on Kubernetes: What Runtime Security Actually Catches

The default Falco ruleset covers the threats that show up most in real incident reports:

• 
  Shells spawned inside containers — exec into a pod, reverse shell from a web app exploit, interactive session from compromised code


• 
  Privilege escalation — a process inside a container attempting to gain root access or modify privileged kernel settings


• 
  Sensitive file access — reads from /etc/shadow, /root/.ssh/, or cloud credential files like ~/.aws/credentials
  


• 
  Unexpected outbound traffic — connections to known crypto-mining pools, C2 servers, or external hosts outside your expected egress

Falco doesn't block any of this by default — it alerts on it. The threat detection is real-time because it happens at the kernel system call layer, not by periodically scanning container state.

Installing Falco on Kubernetes with Helm

Add the Falco Helm repository and update:

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

helm repo update

Basic installation into its own namespace:

helm install falco falcosecurity/falco \

    --create-namespace \

    --namespace falco

By default, Helm deploys Falco as a DaemonSet — one pod per node — with the driver.kind=auto setting, which selects the best available driver automatically.

For most production clusters, you'll want to add Kubernetes metadata collection and Falcosidekick for alert routing:

helm install falco falcosecurity/falco \

    --create-namespace \

    --namespace falco \

    --set driver.kind=modern_ebpf \

    --set collectors.kubernetes.enabled=true \

    --set falcosidekick.enabled=true

This single command gets you: eBPF-based syscall monitoring, Kubernetes pod and namespace metadata enrichment in alerts, and Falcosidekick ready to route alerts to your notification channels.

eBPF vs Kernel Module: Choosing Your Driver

Falco supports three driver options, and the choice has real operational consequences:

For most teams running Kubernetes 1.24+ on standard cloud providers (EKS, GKE, AKS), modern_ebpf is the right choice. The CO-RE (Compile Once, Run Everywhere) approach means the probe adapts to different kernel structures at load time without recompilation — which eliminates the kernel header dependency that makes kmod painful to operate.

To install with explicit modern eBPF:

helm install falco falcosecurity/falco \

    --create-namespace \

    --namespace falco \

    --set driver.kind=modern_ebpf

⚠️ Note: modern_ebpf requires kernel 5.8 or later. For older kernels, use kmod or check the official Falco docs for minimum version requirements by driver type.

Also verify your Kubernetes RBAC policies allow Falco's DaemonSet pods to run with the necessary Linux capabilities — specifically SYS_PTRACE for eBPF-based drivers.

Understanding and Customizing Falco Rules

Falco rules are YAML files. Each rule defines a condition (what to look for in the syscall stream), an output message format (what the alert says), and a priority level. The default ruleset covers common threats out of the box, and you can extend it with custom rules for your environment.

Rules are loaded from /etc/falco/ inside the Falco pod. The main default ruleset lives in falco_rules.yaml. You override rules or add new ones in falco_rules.local.yaml — Falco loads local rules last, so they override defaults.

Common starting points for custom rules:

• Restricting which namespaces are allowed to spawn processes outside the expected set


• Alerting when credentials files are accessed from specific pod labels


• Flagging network connections to unexpected IP ranges from production workloads

For exact condition field syntax and the full list of Falco fields (proc.name, container.image.repository, fd.sport, etc.), see the official Falco documentation. The field reference is comprehensive and the conditions are readable once you know the namespace.

For DevSecOps pipeline integration, Falco rules can be version-controlled and deployed via the same Helm chart upgrade path.

Falco Alert Routing with Falcosidekick

Falcosidekick is the standard companion service for routing Falco alerts. It sits between Falco's JSON event stream and your notification systems, with over 50 built-in integrations.

When you enable Falcosidekick in the Helm install, it deploys alongside Falco and picks up the event stream automatically:

helm upgrade falco falcosecurity/falco \

    --namespace falco \

    --set driver.kind=modern_ebpf \

    --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"

Falcosidekick supports Slack, PagerDuty, Elasticsearch, Splunk, Loki, Datadog, OpsGenie, and many more. You configure each integration through Helm values or a falcosidekick.yaml config file.

[IMAGE: articles/images/2026-07-05-falco-kubernetes-runtime-security-diagram.png | alt: "falco alert routing flow from kernel layer through rules engine to Falcosidekick integrations"]

For alert volume, Falco's priority levels (CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG) let you route only high-priority alerts to PagerDuty while sending everything else to Elasticsearch for analysis.

This pairs well with existing cloud security monitoring — Falco covers the runtime layer that static config scanners miss.

Frequently Asked Questions

Q: Does Falco work on managed Kubernetes like EKS, GKE, or AKS?

A: Yes. All three managed providers support running Falco as a DaemonSet. On GKE, you'll need Container-Optimized OS nodes with the right kernel version for modern_ebpf. EKS and AKS support it on Amazon Linux 2 and Ubuntu node pools respectively.

Q: Will Falco slow down my Kubernetes workloads?

A: The modern eBPF driver has minimal overhead — typically 1-3% CPU on nodes under normal load. The syscall monitoring happens in the kernel, separate from your container processes. Heavy filtering of low-priority events through priority levels keeps the overhead manageable.

Q: Does Falco block threats or only alert?

A: By default, Falco only alerts. For active response — killing a pod, triggering a network policy change — you pair Falco with a response engine. Falco's Kubernetes Response Engine project, or a custom Falcosidekick webhook handler, can trigger automated remediation.

Q: How do I update Falco rules without redeploying the DaemonSet?

A: Use falcoctl — the Falco artifact manager — to pull updated rules at runtime. This is the recommended approach for production: falcoctl artifact install ruleset:falco-rules without a full Helm upgrade.

Q: Can I run Falco alongside other security tools like Trivy or kube-bench?

A: Yes, and you should. Falco covers runtime behavior. Trivy covers image vulnerabilities. kube-bench covers CIS benchmark compliance. These tools address different attack surfaces and complement each other.

Quick Summary:

• Falco monitors kernel system calls via eBPF — it catches runtime threats that config scanners miss


• Install with Helm: driver.kind=modern_ebpf is the right choice for kernel 5.8+ production clusters


• Enable collectors.kubernetes.enabled=true to get pod/namespace context in every alert


• Falcosidekick routes alerts to 50+ integrations — Slack, PagerDuty, Elasticsearch — with a single Helm value


• Custom rules go in falco_rules.local.yaml and load last, overriding defaults


• Falco alerts but doesn't block by default — pair it with a response engine for automated remediation