Kubernetes Runtime Security Compared: Falco vs Tetragon vs KubeArmor

Why you're reading this

You're a platform engineer choosing a runtime security tool for Kubernetes. Network policies stop lateral movement at the boundary. Pod security policies prevent privilege escalation. But none of that catches a compromised container running a reverse shell, crypto miner, or kernel exploit. Runtime security fills that gap—it watches what processes actually do inside the container at kernel level and enforces policy in real time.

Three tools dominate this space: Falco (detection via YAML rules), Tetragon (eBPF enforcement from Cilium), and KubeArmor (LSM-based enforcement per pod). All three work. The question is which one fits your team's ops model, your CNI, and how much kernel-level work you're willing to own.

What runtime security actually catches

Runtime security operates at the syscall level. When a container process executes, reads a file, opens a network socket, or loads a kernel module, the runtime security tool sees it. Network policies can't. Pod security policies can't. A runtime security tool catches:

• Container escapes and privilege escalation attempts.
• Unexpected binaries executing (a cryptominer spawning from a web server).
• Reverse shells and command-and-control callbacks.
• Credential theft and secret exfiltration.
• Kernel exploits and rootkit installation.

The tradeoff: you're watching everything. That means either noise (Falco in default rules), coupling to your CNI (Tetragon), or LSM overhead (KubeArmor). The tool you pick determines how much signal vs noise you tolerate and how much you want to enforce at the kernel versus just alert.

Falco: mature, rules, not free

Falco operates via a kernel module or eBPF probe that streams syscall data to userspace, where a rules engine (written in YAML) evaluates each syscall against your ruleset. The rules are pattern-matching: "if a process named X opens file Y with mode Z, fire alert W."

Strengths: Falco is CNCF graduated and has the largest ecosystem. Its rule library is comprehensive and battle-tested across thousands of clusters. Operators familiar with log-based alerting will recognize the model. Detection only means you stay in pure observability land—no enforcement surprises.

Weaknesses: The kernel module is notoriously fragile across kernel versions; the modern eBPF probe (with CO-RE support) is now fully mature and the recommended driver — the legacy eBPF probe was deprecated in Falco 0.43.0. Rule tuning requires manual work—the defaults fire constantly (cryptominer detections, shell spawning in containers, file writes) because they don't know your workload. You end up writing exception rules for every legitimate operation. Alert fatigue is real. Falco also doesn't stop anything; it only tells you what happened.

Installation:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --set ebpf.enabled=true \
  --set falco.grpc.enabled=true

Tetragon: eBPF-native, Cilium-coupled

Tetragon is Cilium's runtime security sibling. It's eBPF-native (no kernel module option) and policy-driven. You write enforcement rules as Kubernetes resources (TracingPolicy), and Tetragon enforces them at the kernel level. A rule can say "if a process reads /etc/passwd, deny it" and the syscall fails in real time.

Strengths: Enforcement at kernel level means a compromised container can't talk its way out. eBPF overhead is low—you're not buffering syscall data to userspace. Tetragon integrates tightly with Cilium's control plane, so if you're already running Cilium (likely), the operational surface shrinks. The policy language is simpler than Falco rules because it's about what to block, not pattern-matching.

Weaknesses: Tetragon is younger and smaller. If you hit an edge case, the community is smaller. It assumes you're comfortable with eBPF debugging and kernel-level concepts. The Cilium coupling is tight; if Cilium breaks, Tetragon can suffer. If you're not running Cilium, adoption friction is higher.

Installation:

helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon \
  --namespace kube-system \
  --set tetragon.enabled=true

KubeArmor: LSM-based, discovery-friendly

KubeArmor uses the Linux Security Module (LSM) interface or BPF-LSM to enforce policy per pod. You write policy as Kubernetes resources (KubeArmorPolicy) that say "this pod can only read /app and /tmp, execute only /bin/bash and /app/server, and write only to /tmp." KubeArmor generates AppArmor or SELinux policy behind the scenes.

Strengths: Enforcement by default—policies block violations immediately. KubeArmor has a discovery mode that watches a pod and auto-generates a policy, reducing manual work. It doesn't require Cilium; any CNI works. The model is simpler for ops teams: "what's allowed" rather than "what's suspicious." LSM is well-understood and stable.

Weaknesses: Community adoption is smaller. AppArmor availability varies across distributions (spotty on EKS without extra work). BPF-LSM is newer and less hardened than AppArmor. If your pods have wildcard file access patterns, writing policy gets tedious fast. Not CNCF graduated, so enterprise adoption lags.

Installation:

helm repo add kubearmor https://kubearmor.github.io/charts
helm repo update
helm upgrade --install kubearmor kubearmor/kubearmor -n kubearmor --create-namespace

Head-to-head: the matrix

Decision framework: pick your tool

Use Falco if: You want pure observability. You're OK with tuning rules to match your workload. You need the largest rule library and community. You're not ready for enforcement. Your org already runs Falco elsewhere and you want consistency.

Use Tetragon if: You're running Cilium and want to extend it. You want enforcement at the kernel level without extra overhead. You're comfortable with eBPF concepts. Your team can debug eBPF edge cases. You want tight integration between network policy (Cilium) and runtime policy (Tetragon).

Use KubeArmor if: You want enforcement and simplicity. You're starting from zero (no Cilium, no Falco). Discovery mode appeals to you—letting the tool watch a pod and auto-generate policy. Your team is small and you want the least operational surface. You can work around AppArmor / BPF-LSM limitations on your distribution.

Deployment patterns: running them in prod

All three run as DaemonSets. All three need elevated privileges (kernel access). All three need syscall audit enabled on the host.

Falco: Run the DaemonSet with hostNetwork=true and hostPID=true. Configure syslog or GRPC output to a logging backend (Datadog, Sumo, Splunk, or your own pipeline). Set resource limits carefully—default rules are noisy, so pod memory can spike during alert storms. CPU is usually stable.

Tetragon: Run as a DaemonSet. Configure output format (JSON or Compact). Pair with a log aggregator. Resource usage is low and predictable—eBPF does the work in kernel, not userspace buffering. If Cilium restarts, Tetragon will too (they share control plane).

KubeArmor: Run as a DaemonSet. Write your policies as Kubernetes resources. Use discovery mode on a test pod first to generate a policy template, then apply to prod. Resource overhead is the lowest—LSM evaluation is native to the kernel.

The combination play

You don't have to pick one. Some teams run Falco for detection (noisy but comprehensive rules) and KubeArmor or Tetragon for enforcement (your hardened baseline). Falco tells you what you're missing; the enforce-only tool locks down the rest. This hybrid approach is expensive (three tools' overhead), but it's practical for high-risk workloads.

If you're running Cilium already, Tetragon replaces Falco's enforcement and reduces operational load. If you're not, Falco + KubeArmor is a solid middle ground: Falco for breadth, KubeArmor for enforcing the 80% of expected behavior.

The short version

Pick Falco if you want the largest rule library and pure detection. Pick Tetragon if you're running Cilium and want kernel-level enforcement without extra work. Pick KubeArmor if you want simple, whitelist-based enforcement and don't need deep community support. Consider running two tools (Falco for detection, KubeArmor or Tetragon for enforcement) if your security posture demands it. All three are stable for production use; the difference is operational complexity and what you're willing to enforce versus just observe.