This is unreleased documentation for Runtime Enforcer 0.11-dev.

Kubewarden Runtime Enforcer

Kubewarden Runtime Enforcer is a Kubernetes security tool that uses eBPF (Extended Berkeley Packet Filter) to observe process executions in your workloads and to enforce allow-list based security policies at the kernel level.

Kubewarden Runtime Enforcer is a vendor neutral, CNCF Sandbox project, originally created by SUSE Rancher.

It operates in three phases:

  • Learn — observe process executions and generate a WorkloadPolicyProposal per workload.

  • Monitor — report violations of an approved WorkloadPolicy without blocking them.

  • Protect — block executions that violate the policy allow-list.

How does Kubewarden Runtime Enforcer help?

Runtime Enforcer limits each container to the executables that its job needs, and it stops every other executable before it starts.

Benefits and value

  • The allow-list comes from the processes that the workload runs. You do not write it by hand.

  • Each container of a workload has its own allow-list. Init containers and sidecars are covered.

  • Enforcement happens in the kernel, before the process starts. A blocked executable never runs.

  • The policy is attached when the container starts, so it covers the entrypoint, short-lived pods, and commands from kubectl exec.

  • Nothing is enforced until you promote a proposal. Monitor mode shows what a policy blocks before it blocks.

  • A policy is a namespaced resource with no cluster-specific state. You learn it once and apply it to many clusters as code.

  • A kubectl plugin wraps the common tasks. Plain labels and annotations do the same work without it.

  • Runtime Enforcer is part of a CNCF project, with an open community.

Use cases

  • Hardening. Give each workload an allow-list of executables without a manual audit of each image.

  • Containment. Stop an attacker from running a shell, a package manager, or a downloaded tool in a compromised container.

  • Fleet management. Keep the same policy in every cluster, from one Git repository.

There is further documentation of use cases on the use cases page.

New to Runtime Enforcer?

Start with the quick start. It installs Runtime Enforcer, learns a policy for a sample workload, and walks through monitor and protect mode. Then read Phases for the full rules of each phase, and Architecture to see how the controller, the agent, and the kernel work together. Operators find the kernel and container runtime requirements in Compatibility, and the learning scope in Learning mode configuration. Application teams find the day-to-day commands in the kubectl plugin page. The glossary defines the terms that these pages use. Before you deploy to production, verify the release that you install.

What is eBPF?

eBPF is a feature of the Linux kernel. It runs small, verified programs inside the kernel, at points that the kernel exposes. A program can observe an event, such as the start of a process, and it can change the result of that event. Runtime Enforcer loads one such program on each node. The program runs each time a process starts in a container.

Why enforce at process start, in the kernel?

A check in the kernel sees every process, with no gap. There is no agent in the container to bypass, and no race between the start of the process and the check. When the executable is not in the allow-list, the kernel refuses the start. The process never runs, so it cannot do harm before a detection tool reacts.

The policy is attached through the container runtime, before the first process of the container starts. As a result, the entrypoint itself is subject to the allow-list, and so is a pod that lives for one second. A pod whose policy is missing does not start at all. This is the default, so that a mistake in a label does not leave a workload without protection.

Vendor neutrality

Runtime Enforcer is a vendor neutral project as defined by the CNCF.