Open Horizon KubeArmor Demo

Open Horizon KubeArmor Demo – learn about Open Horizon components, demo use cases, deployment, observability, policy recommendation. Open Horizon is a scalable edge-native architecture. Edge is the new attack scenario.

KubeArmor for Zero Trust Edge Security

KubeArmor offers deep observability using eBPF telemetry, granular policies for container isolation.

In this KubeArmor Demo, we dive into how KubeArmor—an open-source Kubernetes-native security solution developed by AccuKnox—brings real-time system-level policy enforcement to containerized environments. Unlike traditional container security tools that focus solely on alerts or network-level defenses, KubeArmor offers actual enforcement of system-level policies, effectively preventing unauthorized activities before damage occurs.

Why System-Level Runtime Security Matters

While container runtime security is often associated with network protection, it’s crucial not to overlook system and data-level defenses. Attackers may bypass the network layer and exploit system-level vulnerabilities—such as leaking Kubernetes credentials, mounting host paths, or executing unauthorized binaries inside containers.

Here’s where KubeArmor excels: it uses Linux Security Modules (LSMs) like AppArmor and SELinux to enforce access and execution policies inline, not just after-the-fact detection. This kind of enforcement is essential for compliance, hardening, and preventing high-impact intrusions.

The Core of KubeArmor’s Security Model

KubeArmor taps into the rich primitives of the Linux kernel, integrating with LSMs to enforce policies at the syscall level. Unlike tools such as Falco and Tracee—which use eBPF to generate alerts—KubeArmor blocks malicious behavior in real time. This gives it a unique position as a policy enforcement engine rather than just an audit tool.

By bridging LSMs and Kubernetes, KubeArmor lets administrators define policies using YAML, which are then automatically translated into LSM-specific syntax appropriate for the underlying node environment. This abstraction layer removes the complexity of writing raw AppArmor or SELinux rules.

KubeArmor Demo: WordPress & MySQL Use Case

To showcase the power of KubeArmor, the demo scenario focuses on a typical WordPress and MySQL stack. This KubeArmor Demo includes four essential policies:

1. Restricting Path Access: Prevents unauthorized processes from accessing sensitive MySQL directories like /var/lib/mysql.
2. Credential Access Control: Blocks unknown processes from reading WordPress config files containing database credentials.
3. Process Execution Restrictions: Limits which executables can run inside containers.
4. Service Account Token Protection: Ensures only designated components access Kubernetes service account tokens.

These policies are directly aligned with MITRE ATT&CK tactics and can be set in either audit or block mode. Unlike most tools, KubeArmor allows inline enforcement, actively preventing policy violations as they occur.

How KubeArmor Works Under the Hood

KubeArmor detects the Linux kernel version and available LSM on each node, ensuring policy compatibility and correctness. It also uses an eBPF-based monitor to enrich security events with Kubernetes metadata, such as pod names and namespaces, allowing for contextual and actionable insights.

While LSMs operate inline, they were never designed with Kubernetes in mind. KubeArmor addresses this by translating high-level Kubernetes policies into LSM rules and applying them automatically across clusters—whether in EKS with SELinux or GKE with AppArmor.

The Future: KRSI and Adaptive Security

Looking forward, KubeArmor is evolving to support Kernel Runtime Security Instrumentation (KRSI)—a powerful eBPF-based runtime security feature introduced in Linux 5.7+. KRSI allows for dynamic, flexible policy definitions as eBPF bytecode, bringing the same innovation seen in tools like Cilium to system-level enforcement.

Alongside this, the team is working on integrating Variational Autoencoders (VAEs) for adaptive process monitoring and provenance analysis for sensitive data tracking. These efforts aim to reduce forensic noise, improve anomaly detection, and make policy generation easier and more automated.

KubeArmor vs. OPA/Gatekeeper

It’s important to note that KubeArmor complements, rather than competes with, policy engines like OPA or Gatekeeper. While OPA governs what gets deployed (admission control), KubeArmor governs what can run and execute at the system level. Together, they offer a comprehensive Kubernetes security posture.

Get Involved

This KubeArmor Demo is just one example of how real-time enforcement can transform container security. If you’re interested in trying it out or contributing, visit the KubeArmor GitHub repository, watch our demo videos, or join the conversation on Slack.

💻 Learn more about AccuKnox
Contact: https://accuknox.com/contact-us
——————————————————
❓Get help with queries
Slack: https://kubearmor.slack.com/
——————————————————
💬 Follow AccuKnox on social media
LinkedIn:   / accuknox  
X:   / accuknox  
——————————————————
✅ Subscribe to Accuknox’s YouTube channel https://www.youtube.com/channel/UCLqK