What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Catalog category is listed as iac-security; KubeArmor is a runtime enforcement tool and may belong under container-security
- Integration list is conservative; confirm the full set of supported forwarders against project documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
KubeArmor enforces behavioral policy inside running containers using the Linux security module layer. Rather than only observing syscalls and raising an alert, it translates a Kubernetes custom resource into AppArmor profiles, BPF-LSM programs or SELinux policy on the node, so a disallowed process execution, file read or network operation is denied by the kernel at the point of attempt. eBPF instrumentation reports both allowed and blocked events with workload context.
Policies are expressed as KubeArmorPolicy custom resources scoped by label selector. A policy names the process paths, file paths, network protocols or capabilities permitted or forbidden, and sets an action of Allow, Audit or Block. That maps cleanly onto a hardening workflow: run in Audit first, observe what a workload actually does, then tighten to Block. KubeArmor also supports host-level policies for VM and bare metal deployments outside Kubernetes.
Where it fits
This is a production control, deployed as a DaemonSet with a per-node enforcement agent. Platform or security engineering owns the policies, though application teams have to be consulted, because a Block policy that is wrong breaks the workload. Two prerequisites matter: your kernel has to support a usable LSM backend, and you need an observation period long enough to build an accurate baseline before enforcing anything.
Strengths
- Actual prevention at the kernel level, not detection after the fact, which is a materially different property from alert-only tooling.
- Audit mode plus event telemetry gives you a practical path from zero knowledge to a tight policy without guessing.
- Policies are Kubernetes-native custom resources, so they version, review and deploy like the rest of your manifests.
- Host and VM support means the same policy model covers workloads that have not moved into containers.
Limitations
- Enforcement capability depends on what the underlying node supports. BPF-LSM availability, AppArmor versus SELinux, and managed Kubernetes distributions that restrict node configuration all change what you actually get, and the difference is not always obvious until you test.
- Writing correct allow-lists is labor intensive. Every legitimate binary, config path and library load has to be accounted for, and applications that self-update will fight you.
- A misconfigured Block policy causes an outage, so the blast radius of a mistake is higher than with a scanner or a detection tool.
Who it suits
Right for teams running sensitive or regulated workloads that can justify the effort of per-workload hardening, and who have control over node configuration. Wrong for teams early in their container security work, who will get more value first from admission control and image scanning, and for anyone running on a managed platform where the required LSM backend is not available.
Used KubeArmor? Recommend it under your own name and title.
Recommend this tool