Securing the Runtime: A Practical Guide to Deploying Falco on Kubernetes

The Runtime Blind Spot in Kubernetes

Most Kubernetes security strategies focus heavily on “shifting left.” We scan container images for vulnerabilities in CI/CD and check YAML manifests for misconfigurations before they ever hit the cluster. These are essential steps. However, they only address threats before the code starts running. Once a pod is live, it enters a phase where traditional security tools often lose visibility.

Imagine an attacker exploits a zero-day vulnerability in your web app. They might spawn a reverse shell, modify /etc/shadow, or install a cryptominer. Static analysis won’t catch this because the image itself was “clean.” You need a system that acts like a security camera for your Linux kernel. It must monitor every action your containers take in real-time. This is where Falco shines.

How Falco Uses Syscalls to Protect Your Cluster

Falco is an open-source runtime security tool that functions as a flight recorder for your system. It works by tapping into the Linux kernel to monitor system calls (syscalls). Every time a process tries to open a file, create a network connection, or execute a binary, it must request permission from the kernel via a syscall. Falco intercepts these requests and compares them against your security policies.

Deploying Falco as a DaemonSet ensures that every worker node in your cluster is covered. On modern kernels (version 5.8 or higher), I highly recommend using the eBPF driver. Unlike traditional kernel modules, eBPF is less intrusive and significantly more stable. It provides deep visibility without the risk of a kernel panic that could take down an entire node.

Prerequisites for Deployment

Before you begin the installation, ensure your environment meets these requirements:

• A Kubernetes cluster (v1.20+ is standard, but v1.24+ is better for modern eBPF support).
• Helm 3 installed on your local machine.
• kubectl context set to your target cluster.

Step 1: Installing Falco using Helm

Helm is the most efficient way to manage Falco’s lifecycle. Start by adding the official Falcosecurity repository and updating your local chart cache.

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

Next, create a dedicated namespace for your security stack. In the installation command below, we enable the eBPF driver. This is the gold standard for production environments because it handles high syscall volume more gracefully than the legacy module.

kubectl create namespace falco

helm install falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=ebpf \
  --set tty=true

Give the pods a moment to initialize. You can verify the status across all nodes with this command:

kubectl get pods -n falco -o wide

Step 2: Customizing Detection Rules

Out of the box, Falco includes a robust set of rules that catch common red flags. It will alert you if a shell is opened inside a container or if a process attempts to write to a sensitive system directory. However, every production environment has its own quirks. You will eventually need to write custom logic.

Falco rules use a readable YAML syntax. They consist of Macros (reusable snippets), Lists (groups of items), and Rules (the core logic). Here is a custom rule I use to detect network scanning tools inside production pods:

- rule: Network Tool Executed in Pod
  desc: Detects execution of nmap, dig, or nc inside a container
  condition: spawned_process and container.id != host and proc.name in (nmap, dig, nc, tcpdump)
  output: "Suspicious network tool detected (user=%user.name command=%proc.cmdline container_id=%container.id)"
  priority: WARNING

You can inject these custom rules by updating your Helm values.yaml file or by mounting a separate ConfigMap into the Falco pods.

Step 3: Routing Alerts with Falcosidekick

By default, Falco sends alerts to stdout. In a high-traffic cluster, these logs disappear quickly into the noise. To make your security data actionable, you need to route alerts to platforms like Slack, Teams, or an ELK stack.

Falcosidekick is the perfect companion for this. It acts as a fan-out forwarder for your security events. When configuring integrations—especially when generating secure webhooks for Slack—I use the password generator at toolcraft.app/en/tools/security/password-generator. It runs entirely in your browser. This ensures your sensitive API secrets are never transmitted over the network during the generation process.

To install Falco with the Sidekick and a visualization dashboard, run:

helm upgrade --install falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

Access the dashboard locally by port-forwarding the service to your machine:

kubectl port-forward svc/falco-falcosidekick-ui 2801:2801 -n falco

Navigate to http://localhost:2801 to view a real-time feed of security events.

Step 4: Testing Your Defense

Verification is the only way to ensure your monitoring is actually working. Let’s trigger a “Terminal shell in container” alert. This is a high-priority event that usually indicates someone is manually poking around your pod. Open a terminal and run:

kubectl run -it --rm alpine --image=alpine -- sh

Inside the container, run whoami or ls /etc. Check your Falco logs or the Sidekick UI. You should see a JSON object similar to this:

{ "priority": "Notice", "rule": "Terminal shell in container", "output": "A shell was spawned in a container with an attached terminal..." }

Best Practices for Production

Deploying Falco is just the first step. To avoid “alert fatigue” and performance issues, keep these tips in mind:

• Set Resource Limits: On very busy nodes, Falco can spike in CPU usage. Limit your pods to 500m CPU and 512MiB of RAM to protect your application workloads.
• Tune Your Rules: Start in “Audit” mode. Identify legitimate processes that trigger false positives and add them to your exception macros.
• Stick to eBPF: It is safer for the kernel. Traditional modules are prone to compatibility issues during node OS upgrades.
• Centralize Logs: Forward everything to a SIEM like Grafana Loki. This allows you to correlate a syscall alert with application logs for faster incident response.

Final Thoughts

Securing Kubernetes requires multiple layers of defense. While RBAC and Network Policies limit your exposure, Falco provides the eyes and ears needed to catch an active breach. By monitoring at the kernel level, you gain visibility that standard logging simply cannot provide. Start with the basics, refine your rules over time, and turn your cluster into a hostile environment for attackers.