Runtime Security Enforcement System. Workload hardening/sandboxing and implementing least-permissive policies made easy leveraging LSMs (LSM-BPF, AppArmor).
2.6k
Stars
507
Forks
362
Open issues
30
Contributors
AI Analysis
KubeArmor is a Kubernetes-native runtime security enforcement system that restricts pod and container behavior (process execution, file access, networking) using Linux Security Modules and eBPF. It serves teams implementing least-permissive workload policies and infrastructure hardening in cloud-native environments; it is specialized for Kubernetes/container security rather than general-purpose access control.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Runtime security enforcement for Kubernetes using LSM and eBPF, with moderate adoption in regulated workloads
KubeArmor is a cloud-native runtime security system that enforces least-permissive policies on pods, containers, and nodes by leveraging Linux security modules (AppArmor, SELinux, BPF-LSM) and eBPF for telemetry. Built for organizations requiring strict workload confinement, compliance auditing (MITRE, CIS, STIGs), and runtime visibility. Adoption appears concentrated in regulated enterprises and platform engineering teams; mainstream Kubernetes adoption remains limited relative to policy-focused competitors like Cilium Tetragon.
Created November 2020, KubeArmor emerged from the need to bridge gap between Kubernetes-native security policies and kernel-level enforcement. Initially incubated as a standalone security project; joined CNCF as Sandbox project, reflecting community validation of the runtime enforcement approach in container security.
Repository shows steady but modest growth: 2,439 stars over ~5.5 years with 6 stars in last 7 days (as of July 2026), suggesting plateaued mainstream interest but not stagnation. Growth likely driven by: (1) increasing compliance requirements in regulated industries, (2) platform teams adopting LSM-based hardening as part of zero-trust strategies, (3) eBPF ecosystem maturation making kernel-level observability more accessible. Recent activity (last push July 2, 2026) indicates active maintenance.
Adoption not verified from README; no case studies, enterprise customer names, or deployment scale metrics provided. Docker Hub pulls metric available but not quantified in README excerpt. Presence in ArtifactHub suggests some Helm chart ecosystem integration. CNCF Sandbox membership indicates community validation but not commercial or large-scale production adoption proof. Real-world usage appears to be adoption not verified based on public documentation.
Based on README: appears to be a layered architecture using eBPF for observability and LSM hooks (AppArmor/SELinux/BPF-LSM) for enforcement. Likely components include: daemon running on each node, policy engine parsing declarative security policies, kernel-level enforcement layer, telemetry aggregator. Supports multiple deployment models (Kubernetes, containerized, VM/bare-metal) suggesting modular design. Exact implementation details not verifiable from README alone.
README references Ginkgo-based test suite (CI badge present) and mentions testing guide in contribution docs. No explicit code coverage percentages provided in README. CII Best Practices and OpenSSF Scorecard badges suggest formal QA processes in place, but depth of coverage not documented.
Strong maintenance signals: (1) last push July 2, 2026 (current as of analysis date), (2) active CI/CD pipeline visible in badges, (3) biweekly community calls documented, (4) FOSSA compliance checks integrated, (5) multiple security certifications (CII Best Practices, OpenSSF Scorecard), (6) 506 forks and established maintainer structure. Not rapidly evolving but consistently maintained.
ADOPT IF: (1) your threat model requires kernel-level confinement beyond network policies, (2) compliance mandates least-permissive enforcement (e.g., DoD STIG, PCI-DSS workload isolation), (3) you have LSM-capable infrastructure (AppArmor/SELinux/BPF-LSM support), (4) your team can maintain policy definitions across the application lifecycle. AVOID IF: (1) your cluster runs on Windows or lacks LSM support, (2) you prioritize observability-first over prevention, (3) you lack expertise in LSM policy syntax or kernel security, (4) your adoption timeline requires battle-tested maturity with extensive public case studies. MONITOR IF: (1) evaluating multi-layer defense-in-depth where KubeArmor could complement NetworkPolicy and RBAC, (2) considering LSM enforcement but uncertain about operational burden, (3) watching for increased adoption signals in regulated industries before committing resources.
Independent dimensions
Mainstream potential
4/10
Technical importance
7/10
Adoption evidence
3/10
- LSM dependency creates platform brittleness: policy enforcement fails silently or unpredictably if kernel LSM support is unavailable, degraded, or misconfigured; no graceful fallback to permissive mode documented in README.
- Adoption remains niche: limited public case studies or vendor endorsements may signal low production maturity; organizations hesitant to adopt enforcement tools without peer examples.
- Policy maintenance burden: least-permissive policies require deep application knowledge and ongoing tuning; potential for operational friction if policies are too restrictive or break legitimate workflows.
- Kernel version fragility: eBPF and BPF-LSM behavior varies across kernel versions; README support matrix existence is good, but cross-kernel compatibility risk remains for heterogeneous clusters.
- Community scale uncertainty: 2,439 stars and modest recent growth suggest smaller ecosystem compared to Cilium/Tetragon; fewer third-party integrations, plugins, or policy templates available.
KubeArmor likely remains a specialized tool for regulated enterprises and high-security platform teams rather than mainstream Kubernetes adoption. Growth will be driven by compliance requirements (SOC2, HIPAA, NIST) rather than performance or feature competition with observability tools. May see increased adoption if BPF-LSM support becomes standard in major Linux distributions and cloud providers simplify LSM enablement.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Website
- https://kubearmor.io/
- Language
- Go
- License
- Apache-2.0
- Last updated
- 14h ago
- Created
- 68mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Top contributors
Similar repos
controlplaneio/kubesec
Kubesec is a security risk analysis tool for Kubernetes resources that performs...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
kubearmor/KubeArmor
this
|
2.6k | +122 | Go | 8/10 | 14h ago |
 kubescape/kubescape
|
11.5k | — | Go | 8/10 | 16h ago |
 cilium/tetragon
|
4.8k | — | C | 8/10 | 15h ago |
|
controlplaneio/kubesec
|
1.5k | — | Go | 8/10 | 2w ago |
 aquasecurity/tracee
|
4.5k | — | Go | 8/10 | 23h ago |
 stackrox/kube-linter
|
3.5k | — | Go | 8/10 | 2d ago |
Both use eBPF for runtime visibility; Tetragon broader observability focus, KubeArmor emphasizes enforcement via LSM. Tetragon has 2x the GitHub attention; KubeArmor more explicit about least-permissive policy patterns.
Both leverage eBPF; Tracee focused on threat detection and forensics, KubeArmor on policy enforcement. Different threat models: Tracee reactive, KubeArmor preventive.
Kubescape is static/config auditing; KubeArmor is runtime enforcement. Complementary rather than competitive—Kubescape finds policy gaps, KubeArmor enforces them at runtime.
Policy linting at deploy time; KubeArmor enforces at runtime. KubeArmor addresses runtime deviation, kube-linter prevents misconfiguration before deployment.
Kubesec scores security configurations; KubeArmor enforces behavioral restrictions. Orthogonal goals—KubeArmor adds behavioral layer beyond configuration hardening.
