Skip to content
KubeArmor

KubeArmor

Category: IaC Security
License: Free (Open-Source, Apache 2.0)
Suphi Cankurt
Suphi Cankurt
AppSec Enthusiast
Updated February 7, 2026
3 min read
Key Takeaways
  • KubeArmor actively enforces runtime security policies at the kernel level using Linux Security Modules (AppArmor, SELinux, BPF-LSM) and eBPF, blocking violations before they occur.
  • CNCF Sandbox project with 2.1k GitHub stars, 1.2M+ downloads; deploys as a non-privileged DaemonSet requiring no application code or image changes.
  • Ships pre-built compliance policies for CIS, MITRE ATT&CK, NIST 800-53, and STIGs; controls process execution, file access, and network operations per pod.
  • Supports EKS, GKE, AKS, and bare metal; available on AWS, Red Hat, Oracle, and DigitalOcean marketplaces.

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.

KubeArmor overview showing runtime enforcement across Kubernetes, containers, and VMs

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.

KubeArmor architecture diagram showing policy enforcement flow from Kubernetes to kernel LSMs

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.

Least-Privilege Enforcement
Automatically restricts workloads to only necessary capabilities, reducing attack surface without manual security context configuration
Zero-Code Hardening
Apply security policies to existing applications without modifying code, rebuilding images, or changing deployment manifests
Compliance Libraries
Deploy pre-built policies based on CIS, MITRE, NIST, and STIG frameworks to meet regulatory requirements out-of-the-box

Key Features

FeatureDetails
Enforcement mechanismLinux Security Modules (AppArmor, SELinux, BPF-LSM)
InstrumentationeBPF-based telemetry with container/pod/namespace identities
Policy scopeProcess execution, file access, network operations
Compliance rulesMITRE ATT&CK, STIGs, CIS-based pre-built policies
DeploymentNon-privileged DaemonSet on Kubernetes, containers, VMs/bare-metal
MarketplacesAWS, Red Hat, Oracle, DigitalOcean
CNCF statusSandbox
LicenseApache 2.0

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

1
Install KubeArmor — Deploy via Helm or from the AWS/Red Hat/Oracle/DigitalOcean marketplace. KubeArmor runs as a non-privileged DaemonSet on every node.
2
Apply a pre-built policy — Start with MITRE, STIGs, or CIS-based compliance policies from the KubeArmor policy library. These cover common hardening requirements out of the box.
3
Write custom policies — Define policies using Kubernetes CRDs that specify match criteria (pods, namespaces) and enforcement rules (allow/deny for processes, files, network).
4
Monitor violations — KubeArmor logs policy violations with full container/pod/namespace identity context via eBPF telemetry.

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
Best for
Organizations requiring strict runtime security enforcement for containerized workloads in regulated industries. Ideal for zero-trust architectures where workloads should be restricted to minimal necessary behaviors.

For a broader view of container security strategy, see our cloud infrastructure security guide. 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

What is KubeArmor?
KubeArmor is a CNCF Sandbox runtime security enforcement system that restricts container and pod behavior using Linux Security Modules and eBPF. It enforces security policies on process execution, file access, and network operations without requiring changes to applications or container images.
How does KubeArmor differ from Falco?
While Falco detects and alerts on policy violations, KubeArmor actively prevents violations by enforcing policies through kernel-level LSMs. Falco is detection-focused, KubeArmor is enforcement-focused. Many organizations use both together—KubeArmor to prevent known threats and Falco to detect unknown threats.
Which Linux Security Modules does KubeArmor support?
KubeArmor works with AppArmor, BPF-LSM, and SELinux depending on what’s available in the kernel. It automatically selects the appropriate LSM, preferring BPF-LSM on modern kernels for its flexibility and BPF-based implementation.
Can KubeArmor work in cloud-managed Kubernetes?
Yes, KubeArmor supports major managed Kubernetes services including EKS, GKE, and AKS. AWS recently highlighted KubeArmor’s integration with EKS Auto Mode for enhanced container security in managed environments.