KubeArmor — Runtime Security Enforcement for Kubernetes

Introduction

KubeArmor is a CNCF sandbox project that provides runtime security enforcement for Kubernetes workloads. Unlike tools that only detect threats after the fact, KubeArmor actively blocks unauthorized operations at the kernel level using eBPF and Linux Security Modules (LSM), enforcing zero-trust security policies on processes, files, and network activity.

What KubeArmor Does

• Enforces security policies on process execution, file access, and network connections
• Uses eBPF and LSM hooks to block unauthorized operations at the kernel level
• Provides default deny postures for hardening containers beyond seccomp and AppArmor
• Generates visibility logs of all system-level activity for forensics and compliance
• Recommends security policies based on observed workload behavior

Architecture Overview

KubeArmor runs as a DaemonSet on each node. The KubeArmor daemon attaches eBPF programs and LSM hooks to enforce policies at the kernel level. It watches KubeArmorPolicy CRDs and translates them into kernel-level rules. A relay server aggregates telemetry from all nodes and exposes it via gRPC. The karmor CLI and KubeArmor operator provide management interfaces for policy creation and cluster-wide configuration.

Self-Hosting & Configuration

• Install via the karmor CLI, Helm chart, or operator
• Deploy KubeArmorPolicy CRDs to define per-workload security rules
• Configure default posture (audit or block) for processes, files, and network
• Enable telemetry export to SIEM systems via the relay server's gRPC API
• Use karmor recommend to auto-generate policies from workload profiling

Key Features

• Kernel-level enforcement via eBPF and LSM prevents bypass at the application layer
• Fine-grained policies on process paths, file paths, and network protocols
• Workload-aware policy binding using Kubernetes label selectors
• Auto-generated policy recommendations from observed runtime behavior
• Visibility mode for auditing before switching to enforcement

Comparison with Similar Tools

• Falco — detects and alerts on runtime threats but does not block them by default
• Seccomp — system call filtering at the container level, less granular than KubeArmor policies
• AppArmor/SELinux — mandatory access control at the OS level, harder to manage per-pod
• Tetragon — eBPF-based observability and enforcement by Cilium, different policy model

FAQ

Q: Does KubeArmor require changes to application code? A: No. KubeArmor operates at the kernel level and is completely transparent to applications running inside containers.

Q: What kernel features does KubeArmor require? A: KubeArmor requires eBPF support (Linux 4.15+) and optionally BPF LSM (Linux 5.7+) for full enforcement. On older kernels, it falls back to AppArmor or SELinux.

Q: Can I use KubeArmor in audit-only mode first? A: Yes. Set the default posture to Audit to log policy violations without blocking. Switch to Block after validating that policies match expected behavior.

Q: How does KubeArmor differ from network policies? A: Kubernetes NetworkPolicy controls pod-to-pod network access. KubeArmor controls what processes, files, and syscalls are allowed inside a pod, providing a complementary layer of defense.

Sources

• https://github.com/kubearmor/KubeArmor
• https://docs.kubearmor.io/