# Runtime security for Kubernetes

> Canonical: https://juliet.sh/kubernetes-security/runtime-security
> Category: Controls
> Last reviewed: 2026-04-01

## Short answer

Runtime security watches containers while they execute and flags or blocks malicious behavior: reverse shells, crypto miners, suspicious exec into production pods, unexpected network connections, credential access. Modern runtime security uses **eBPF** to hook kernel events (syscalls, network packets, process exec) with low overhead and no sidecar per pod. Two widely used open-source projects in the space are **Falco** (detection) and **Tetragon** (detection and enforcement).

## Why runtime matters even with strong posture

Posture and admission block known-bad configurations. Runtime is there to catch what gets past them:

    - A compromised dependency that only activates on a specific input.

    - A stolen Kubernetes credential being used from an attacker's pod.

    - A zero-day in a popular base image.

    - A legitimate pod that suddenly executes a shell command or pulls a remote script.

Without a runtime layer, the cluster is blind the moment an attacker gains a foothold that passes static checks.

## eBPF, audit logs, and sidecars

**eBPF** runs small verified programs inside the Linux kernel. It sees syscalls, sockets, and file access at single-digit percent overhead. This is the modern baseline and what Juliet, Falco, and Tetragon all use.

**Audit logs** (Kubernetes API server audit log, Linux auditd) show what happened after the fact, from userspace. Cheap but delayed, and scoped only to specific events.

**Sidecars** used to be the default runtime architecture, with a DaemonSet per node or, in the worst case, a sidecar per pod. eBPF has largely replaced the sidecar model because it offers deeper visibility with less footprint. [How we replaced a Falco sidecar with an embedded eBPF sensor](/blog/building-runtime-enforcement-for-kubernetes-with-ebpf).

## Detection and enforcement

**Detection** flags suspicious behavior for a human to triage. Safe, with no risk of breaking workloads, but slower to respond.

**Enforcement** blocks or kills the offending process in real time. Powerful, but a false positive that stops a production pod is a meaningful outage. Enforcement usually starts narrow (specific CVE exploit signatures or well-understood attacker behavior) and expands after observation.

A typical adoption path runs detection in audit mode first, then promotes a subset of high-confidence rules to enforcement. Juliet supports both: Pro plans include runtime detection (audit), Enterprise adds runtime enforcement.

## What a runtime rule looks like

A classic Falco rule alerts when a shell is executed in a container. In Juliet, the same rule is scoped by pod metadata (production namespace, specific workload labels), filtered by parent process, and correlated with the cluster graph. A shell spawned in an internet-exposed pod bound to cluster-admin becomes a high-severity event. The same event on a developer's debug pod is down-ranked or suppressed.

## Frequently asked

### Does runtime security require privileged pods?

The runtime agent needs elevated capabilities (or a privileged pod with hostPID and hostNetwork) to attach eBPF programs. That is the DaemonSet. Application workloads stay non-privileged.

### What is the overhead of eBPF runtime monitoring?

Typically single-digit percent CPU on monitored nodes, depending on rule complexity and syscall volume. Well-written eBPF filters drop most uninteresting events in the kernel before userspace ever sees them.

### Falco or Tetragon?

Both are solid. Falco has a larger community and simpler rules. Tetragon (from Isovalent, now Cisco) adds enforcement and deeper policy integration. Commercial runtime products often build on one of them or on independent eBPF stacks.

### Can I run runtime security without an agent in the cluster?

No. Kernel-level visibility requires a process on each node. The meaningful question is whether it is one DaemonSet (eBPF) or per-pod sidecars. DaemonSet is now the default.

### How does runtime security correlate with posture?

Good runtime tools plug into the same graph as posture. When a runtime alert fires on a pod, the graph immediately surfaces that pod's image, CVEs, RBAC, and reachable attack paths. Shared context is the value a [CNAPP](/kubernetes-security/what-is-cnapp) adds on top of standalone runtime.

## Related

- [eBPF for Kubernetes security](https://juliet.sh/kubernetes-security/ebpf-security)
- [Attack path analysis](https://juliet.sh/kubernetes-security/attack-path-analysis)
- [Kubernetes admission control](https://juliet.sh/kubernetes-security/admission-control)
- [What is CNAPP?](https://juliet.sh/kubernetes-security/what-is-cnapp)