Controls

Runtime security for Kubernetes

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.

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 about runtime security for kubernetes

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 adds on top of standalone runtime.

See this in your clusters

Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.