Falco Runtime Security Tutorial: Catch Attacks as They Happen

Most security tools check your code before it ships. Falco watches what is actually happening while your application runs. This Falco runtime security tutorial shows you how to install Falco on a Kubernetes cluster, see it catch a real suspicious action, and write your own custom detection rule. 

TL;DR Summary

• This Falco runtime security tutorial shows you how to install Falco on Kubernetes and catch suspicious activity the moment it happens, not after the fact.
• Falco is a free, CNCF-graduated tool originally created by Sysdig that watches Linux kernel system calls in real time.
• It catches things static scanners cannot: a shell spawned inside a container, a sensitive file read, a privileged pod created.
• Install with Helm in under 5 minutes, Falco runs as a DaemonSet on every node.
• Falco ships with a strong default ruleset, and writing your own custom rule takes just a few lines of YAML.

What is Falco?

Falco is an open-source, CNCF-graduated runtime security tool originally created by Sysdig. It hooks into the Linux kernel using eBPF and watches system calls in real time, the actual low-level actions every process on a machine performs.

When a running process matches one of Falco’s rules, a shell opened inside a container, a sensitive file like /etc/shadow being read, or a package manager launched unexpectedly, Falco fires an alert immediately. It works across hosts, containers, and Kubernetes, and is considered the de facto standard for Kubernetes runtime security.

Why Runtime Security Is Different From Static Scanning

Tools that scan your code or container image catch known vulnerabilities before deployment. They never see what happens after a container actually starts running.

RBAC controls what users can do through the Kubernetes API. Network policies control which pods can reach each other. Neither one sees what is happening inside a running container, which processes are spawning, which files are being touched. This is exactly the gap Falco fills.

Runtime security is becoming essential knowledge for DevOps and platform engineers in 2026. If you want to build the broader Kubernetes and infrastructure foundation that tools like Falco protect, HCL GUVI’s DevOps Course covers containers, CI/CD, and real-world projects with NSDC certification.

Falco Runtime Security Tutorial: Installation on Kubernetes

You need kubectl and helm installed, along with access to a Kubernetes cluster running Linux nodes. Docker Desktop on Windows or macOS will not work for this, you need real Linux nodes, x86_64 or ARM64.

Add the Falco Helm repository:

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

Install Falco into its own namespace:

helm install falco falcosecurity/falco –namespace falco –create-namespace –set tty=true

Falco deploys as a DaemonSet, meaning one Falco pod runs on every node in your cluster automatically. Wait for the pods to become ready:

kubectl wait pods –for=condition=Ready –all -n falco

Since version 0.40, Falco recommends the modern eBPF driver for kernels 5.8 and above, which needs no kernel headers or compilation, making installation noticeably simpler than older Falco versions.

Seeing Falco Catch Its First Alert

The fastest way to understand this Falco runtime security tutorial is to watch it catch something live.

Open a shell inside any running container in your cluster:

kubectl exec -it <pod-name> — /bin/sh

Check Falco’s logs in a separate terminal:

kubectl logs -n falco -l app.kubernetes.io/name=falco -f

Within seconds, you should see an alert fire, something like “A shell was spawned in a container with an attached terminal,” along with the user, the container image, and the full command line. This is Falco’s default ruleset working exactly as intended, catching a behaviour that is completely normal during debugging but highly suspicious during a real attack.

Understanding Falco’s Default Rules

Falco ships with a comprehensive set of default rules covering common attack patterns. List everything currently loaded with:

falco –list

Or inside Kubernetes:

kubectl exec -n falco -it $(kubectl get pods -n falco -l app.kubernetes.io/name=falco -o jsonpath='{.items[0].metadata.name}’) — falco –list

Each rule has three core parts: a condition that defines exactly what triggers it, an output template describing the alert message, and a priority level like NOTICE, WARNING, or CRITICAL. Default rules cover shell spawning, sensitive file reads, unexpected outbound connections, and privileged pod creation among many others.

Writing a Simple Custom Rule

Falco’s real power in any Falco runtime security tutorial shows up once you start writing rules specific to your own environment. Here is a simple example that flags privileged pod creation:

- rule: Create Privileged Pod
  desc: Detect creation of privileged pods
  condition: >
    kevt and kcreate and ka.target.resource = "pods"
    and ka.req.pod.containers[0].privileged = true
  output: >
    Privileged pod created (user=%ka.user.name pod=%ka.target.name
    ns=%ka.target.namespace image=%ka.req.pod.containers[0].image)
  priority: WARNING
  source: k8s_audit

This rule uses the k8s_audit source, which means it needs the Kubernetes API server configured to send audit events to Falco. Once active, any privileged pod created anywhere in your cluster triggers an immediate, clearly labelled alert.

Common Mistakes to Avoid

• Treating Falco as a replacement for static scanning. Falco catches runtime behaviour, not vulnerable dependencies or insecure code. Pair it with a static analysis tool to cover both ends of the security lifecycle.
• Ignoring alert volume in production. Default rules can be noisy on a busy cluster. Tune rule sensitivity and route alerts to a proper destination like Slack or PagerDuty instead of letting them pile up unread in logs.
• Forgetting to configure Kubernetes audit logging for k8s_audit rules. Rules based on the k8s_audit source, like the privileged pod example above, will silently never fire unless the API server is actually sending audit events to Falco.

Conclusion

This Falco runtime security tutorial covered the full beginner workflow: installing Falco with Helm on Kubernetes, watching it catch a real shell-spawn alert, exploring the default ruleset, and writing a custom rule for privileged pod detection. Static scanning catches problems before deployment. Falco catches them the moment they happen inside a running cluster, and that distinction is exactly why both belong in a serious security setup.

FAQs

1. Is Falco free to use?

Yes. Falco is fully open-source and free, with no licensing cost for any core features covered in this Falco runtime security tutorial.

2. What is the difference between Falco and a static security scanner?

Static scanners check code or images before deployment. Falco watches actual running processes and system calls in real time, catching threats only visible once a workload is running.

3. Does Falco work outside of Kubernetes?

Yes. Falco can run on bare metal hosts and standalone Docker containers, not just Kubernetes clusters.

4. What kernel driver does Falco use?

Modern eBPF is the recommended driver since version 0.40, requiring no kernel headers or compilation for kernels 5.8 and above.

5. Can I write my own Falco rules?

Yes, in YAML with a condition, output message, and priority level, as shown in the custom rule example above.