# KubeArmor: LSM-backed runtime enforcement for pods, containers and nodes > KubeArmor writes least-permissive rules for process, file and network behaviour and enforces them through AppArmor, SELinux or BPF-LSM, while eBPF produces the telemetry. It suits Kubernetes operators who already know which binaries their workloads should run. **kubearmor/KubeArmor** — Runtime Security Enforcement System. Workload hardening/sandboxing and implementing least-permissive policies made easy leveraging LSMs (LSM-BPF, AppArmor). - Repository: https://github.com/kubearmor/KubeArmor - Website: https://kubearmor.io/ - Stars: 2,621 · Forks: 529 - Language: Go - License: Apache-2.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/kubearmor-kubearmor ## The problem KubeArmor targets: behaviour, not images Most container scanning stops at the image. It tells you a package has a known CVE, then the container starts and nothing constrains what the process inside it does next. KubeArmor addresses that gap at the system call boundary. The README describes it as a cloud-native runtime security enforcement system that restricts the behaviour of pods, containers and nodes, naming process execution, file access and networking operations as the three categories it governs. The audience is narrower than the tagline suggests. Someone running a single VM with a handful of long-lived services gets little from a policy engine tied to pod identity. The project pays off where many workloads share a kernel and you already know, or can find out, which executables each one legitimately runs. Its own documentation frames the goal as least-permissive access, with process whitelisting and network whitelisting listed as the two headline capabilities, alongside hardening of critical paths such as certificate bundles and restrictions on raw database table access. ## How enforcement works: LSM hooks plus eBPF telemetry KubeArmor does not implement its own sandbox. It translates a policy into the primitives of whichever Linux security module the host provides. The README names AppArmor, SELinux and BPF-LSM as the supported backends, and the repository topics include both bpf and lsm, which matches that split: policy decides what is allowed, the LSM decides how the kernel blocks the rest. Telemetry is a separate path. The README states that KubeArmor generates alerts and events with container, pod and namespace identity by using eBPF, so an observed process execution or connection can be attributed to a workload rather than to a bare PID. That attribution is what makes the policy authoring loop workable: you watch real behaviour, then write rules that describe it. The repository shows the shape of the codebase rather than the internals. There are KubeArmor/ and BPF/ directories built separately in the Dockerfile, a pkg/ tree shared between them, and a protobuf/ directory, which indicates a gRPC surface between components. The README credits Tracee's system call utility functions as a dependency, so part of the syscall handling is inherited rather than written from scratch. ## Installing KubeArmor and applying a first policy The README points to the getting-started deployment guide and to a support matrix that lists which kernels and distributions are covered. Read the matrix before anything else, because the LSM available on the node determines whether a policy is enforced or only reported. The README links an ArtifactHub listing for KubeArmor, which is where the Helm chart is published, and the project also publishes a container image under the kubearmor organization on Docker Hub. The getting-started deployment guide is the authoritative source for the exact install commands for each deployment model; the README does not reproduce them inline, so follow that guide rather than an abbreviated form. After installation, the README documents a Kubernetes deployment model, a containerized deployment model and a VM or bare-metal deployment model, so the same engine can run outside a cluster when you only need host-level rules. Policies themselves are Kubernetes objects. The repository ships examples under examples/, including kubearmor_containerpolicy.yaml and directories for host, network and cluster policies, with separate specification documents linked from the README for pod, cluster, host and network policy types. The KubeArmorPolicy object carries a selector and an action, and the policy specification lists the full set of match criteria. Apply a policy with kubectl apply -f and the selector decides which pods it covers. Start with a block-and-alert posture if you are unsure of the baseline, since an allow list written from guesswork will break a running workload. ## What KubeArmor cannot do for you Enforcement depends on the host. If the node's kernel has no usable LSM, or the module is not loaded, there is nothing for KubeArmor to program, and the README's support matrix exists precisely because that coverage is uneven. This is the first thing to verify and the easiest to skip. Second, a policy engine only expresses the rules you give it. KubeArmor will not infer that a workload should never open a shell; you have to observe the workload, decide the boundary and write it. The project's own use-case documentation leans on published rule sets such as MITRE, STIGs and CIS as starting points, which is an admission that hand-authoring from zero is the hard part. Third, this is not an image scanner or a vulnerability database. It constrains runtime behaviour. A container running a vulnerable library that stays within its allowed process and file paths will keep running. Teams looking for CVE detection in images need a different tool in the pipeline. Finally, the operational cost is real. Every policy that denies a path or a binary is a potential outage the first time a legitimate code path hits it. The project's release notes show release candidates such as v1.7.6-rc1 alongside stable tags like v1.7.5, which is a normal cadence but also a reminder that you are tracking a moving component that sits in the kernel's enforcement path. ## KubeArmor compared with Falco and Tetragon The three are often mentioned together, and the split is about what happens after detection. Falco is a detection engine: it evaluates rules against events and raises alerts, and its documentation centres on the rule language and the alert outputs. KubeArmor's README describes enforcement, restricting behaviour at the system level through an LSM. If your requirement is an audit trail of suspicious activity, Falco answers it; if your requirement is that the activity cannot happen, KubeArmor is the closer fit. Tetragon also uses eBPF and also offers enforcement, so the difference is smaller. The distinction worth checking in their respective documentation is the policy model and the backend: KubeArmor expresses rules as Kubernetes objects with pod selectors and can fall back to AppArmor or SELinux where BPF-LSM is unavailable, while Tetragon's tracing and enforcement are built around eBPF programs and its own policy format. On a kernel without BPF-LSM, that fallback matters, because it decides whether you can enforce anything at all. Kyverno is a different category again. It is an admission-time policy engine for Kubernetes resources, validating and mutating manifests before workloads are created. KubeArmor acts after the pod is running. The two are complementary rather than competing: Kyverno can reject a privileged pod, and KubeArmor can restrict what a pod does once it is admitted. ## Maintenance, release process and licence The repository is not archived, and the last push was on 2026-09-23, days before this writing, so the project is under active development. Releases are frequent: v1.7.5 landed on 2026-09-11 and v1.7.6-rc1 on 2026-09-20. The presence of release candidates in the tag list means you should pin to stable tags such as v1.7.5 rather than tracking the newest tag by default. The project documents its own process. RELEASES.md covers cadence, release candidates, the release manager role and the support window, so the upgrade question has a written answer rather than an inferred one. A STABLE-RELEASE file sits at the repository root, which is the quickest place to check what the maintainers currently consider stable. Governance is documented too: GOVERNANCE.md describes roles, decision-making and sub-teams, and MAINTAINERS.md lists maintainers, reviewers and emeritus maintainers with affiliations. KubeArmor is a CNCF sandbox project, and the README points to a security policy for vulnerability reports. The licence is Apache-2.0, stated in the repository's LICENSE file and in the SPDX headers on source files such as the Dockerfile. Apache-2.0 is permissive and includes an explicit patent grant, which matters for a component that ships kernel-adjacent code. The README's badge list also references FOSSA licence and security scans and an SLSA Level 3 verification workflow, so dependency and build provenance checks are part of the project's own tooling. None of that is legal advice; if you redistribute a modified build, read the licence text and the NOTICE conventions yourself. ## Conclusion Adopt KubeArmor when you can name the binaries and paths your workloads are allowed to touch and you want that list enforced in the kernel rather than merely logged. Do not adopt it as an audit-only tool or on hosts where you cannot pick an LSM module, because enforcement depends on AppArmor, SELinux or BPF-LSM being available. Before rolling it out, check the KubeArmor Support Matrix for your kernel and distribution, and read the release process in RELEASES.md to see which versions still receive fixes. ## FAQ ### What is runtime security in the context of KubeArmor? It means constraining what a workload does while it runs, rather than what it contains. KubeArmor restricts process execution, file access and networking operations of pods, containers and nodes at the system level, using AppArmor, SELinux or BPF-LSM to enforce the rules. ### Which Linux security modules does KubeArmor support? The README names AppArmor, SELinux and BPF-LSM as the LSMs it uses to enforce user-specified policies. Which one is usable depends on the host kernel and distribution, which is why the project publishes a support matrix. ### How do I install KubeArmor on Kubernetes? The README links a getting-started deployment guide and an ArtifactHub listing for the Helm chart. The project also documents containerized and VM or bare-metal deployment models. ### Is KubeArmor the same thing as Falco? No. Falco is described as a detection engine that raises alerts, while KubeArmor's README describes a runtime security enforcement system that restricts behaviour through Linux security modules. Detection and enforcement are different jobs, though both use kernel-level event sources. ## Sources - [kubearmor/KubeArmor on GitHub](https://github.com/kubearmor/KubeArmor) - [License: Apache-2.0](https://github.com/kubearmor/KubeArmor/blob/main/LICENSE) - [Project website](https://kubearmor.io/) - [README](https://github.com/kubearmor/KubeArmor/blob/main/README.md) - [Releases](https://github.com/kubearmor/KubeArmor/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kubearmor-kubearmor