KubeArmor

KubeArmor is a CNCF Sandbox runtime security enforcement system that restricts container and pod behavior at the kernel level using Linux Security Modules (LSMs) and eBPF. Unlike detection-only tools, KubeArmor actively prevents policy violations by enforcing controls on process execution, file access, and network operations.

The project has 2.1k GitHub stars, 121 contributors, and over 1.2 million downloads. The latest release is v1.6.8 (February 2026). KubeArmor is available on the AWS, Red Hat, Oracle, and DigitalOcean marketplaces. It was the first Kubernetes security engine to use BPF-LSM for inline mitigation.

What is KubeArmor?

KubeArmor deploys as a non-privileged DaemonSet on Kubernetes nodes. When workloads start, it applies security policies that define allowed behaviors. Any attempt to violate a policy — a container trying to execute an unauthorized binary or access a restricted file — is blocked by the LSM before it can occur.

The tool uses eBPF to instrument kernel security hooks with minimal overhead. KubeArmor automatically selects the most appropriate LSM based on what’s available in the kernel (AppArmor, SELinux, or BPF-LSM).

Policies are defined using Kubernetes CRDs that specify match criteria (which pods or namespaces to apply to) and security rules (what behaviors to allow or deny). Teams can write custom policies or use pre-built policy libraries based on compliance frameworks like CIS, MITRE ATT&CK, NIST 800-53, and STIGs.

Key Features

Multi-LSM Support

KubeArmor works with AppArmor on Ubuntu/Debian systems, SELinux on Red Hat/CentOS, and BPF-LSM on modern kernels (5.7+). This flexibility covers different Linux distributions and Kubernetes environments.

Process Control: Policies can restrict which binaries containers can execute. For example, a web server container might be limited to running only nginx and related utilities, preventing attackers from running shells or other tools after compromise.

File System Protection: Fine-grained control over file access prevents containers from reading sensitive files or writing to system directories. Policies can specify read/write/execute permissions for specific paths or patterns.

Network Restrictions: KubeArmor can limit network connectivity from containers, restricting which ports or protocols workloads can use. This capability helps prevent lateral movement after initial compromise.

Kubernetes Integration: Policies reference Kubernetes metadata like namespaces, labels, and container names. This native integration allows security teams to think in Kubernetes terms rather than low-level kernel constructs.

Getting Started

When to Use KubeArmor

Strengths:

• Active prevention rather than detection-only monitoring
• Uses proven kernel security mechanisms (LSMs)
• No application code or image changes required
• Pre-built compliance policies accelerate deployment
• Native Kubernetes integration with CRD-based policies
• Supports major managed Kubernetes services including EKS
• CNCF project with growing community adoption

Limitations:

• Requires kernel LSM support (not available in all environments)
• Policy development requires understanding of application behavior
• Overly restrictive policies can break legitimate functionality
• Debugging policy violations can be challenging
• Limited tooling compared to more mature projects
• Performance impact from LSM enforcement on high-throughput workloads

KubeArmor complements other IaC security tools in a defense-in-depth strategy. Combining KubeArmor’s enforcement with Falco’s detection provides both prevention and monitoring. Policy engines like Kyverno prevent misconfigured workloads from being admitted, while KubeArmor enforces runtime behavior restrictions. This layered approach addresses security at admission, deployment, and runtime phases of the workload lifecycle.

Frequently Asked Questions