KubeArmor is an open-source solution Accuknox, whereas Sysdig has open-sourced Falco, and Aquasec has open-sourced Tracee.
TLDR; The key difference is Auditing vs Protection. KubeArmor provides run-time protection and enforcement whereas Falco and Tracee provide auditing and visibility.
What is KubeArmor and what problem does it solve?
KubeArmor is a run-time enforcement system that can be thought of as an application firewall, allowing us to limit a workload's behavior at run-time. With KubeArmor, you can restrict specific file paths, network access, process forking, and other malicious behavior of cloud workloads at run-time. Think of KubeArmor as guardrails for your application workloads when it is running.
Shown here is a demonstration with MITRE Tactics, Techniques, and Procedures (TTPs), a pod could typically exec into a container, try to mount hostPath and subsequently try to access restricted files and paths as well as communicate back to its remote host with sensitive data once access has been gained.
KubeArmor reduces the attack surface for cloud workloads by using security controls such as LSMs (Linux Security Modules) for confining and limiting process execution and file system access.
Sample MITRE ATT&CK Framework Policy for blocking untrusted shell execution with KubeArmor
LSM hooks have been traditionally used by security engines such as AppArmor, SELinux primarily for host-based security. Extending the same primitives to k8s or containerized workloads is a non-trivial task. KubeArmor uses LSMs including AppArmor, SELinux, (BPF-LSM in the near future) for applying LSM security controls in the context of a given pod.
The primary differentiation between KubeArmor and other event-auditing frameworks such as Sysdig Falco, and AquaSec Tracee is that KubeArmor does runtime blocking and enforcement apart from auditing. This means that while other auditing systems can detect a violation, KubeArmor can block the violation such as file access or the process fork depending on the user-specified or auto-recommended policy.
Importance of Security Controls
Security controls allow KubeArmor to enforce a restriction before the corresponding access attempt is made. For example, if the attacker calls `unlink()` and there exists a policy to block that action. In this case, the block operation would be performed before the file is unlinked. This seems very logical but there are engines available out there that are purely auditing engines that cannot handle inline blocking of such security controls. In such auditing systems, when an unlink is attempted, the event would be raised and an alert monitoring system would then take a remediation action such as to kill the process. But by the time the process is killed the attacker might have succeeded in achieving its goal of deleting the files.
KubeArmor’s provide remediation inline in the kernel space itself based on LSM hooks.
Use of LSMs for Security Controls
AppArmor and SELinux have been traditionally shipped with popular distributions in host-based environments. Even for managed kubernetes engine’s worker nodes, most of the images already ship with either AppArmor or SELinux enabled. For instance, GKE (Google Kubernetes Engine) by default uses the Container Optimized OS (COS) image for its worker nodes. COS ships by default with AppArmor LSM enabled. EKS (Amazon Elastic Kubernetes Engine) Bottlerocket and Amazon Linux 2 ships with SELinux enabled. EKS in certain hardened images also provides default host-based SELinux security policies.
The point is, LSM based security controls are already available by default enabled in most of the images in popular distributions, managed Kubernetes, and cloud engines.
BPF LSM based policies are coming
BPF LSM is a new breed of stackable LSM that allows one to specify eBPF bytecode in the context of LSM hooks for policy enforcement. This would mean that a security engine will no longer be tied to the policy constructs as provided by AppArmor and SELinux and can generate contextual bytecode based on the security requirement at hand. BPF LSM being a stackable LSM means that it can be used along with existing AppArmor or SELinux-based policies. In general, KubeArmor intends to eventually utilize BPF LSM for providing pod-based security policies and make use of an existing pool of policy documents available for host-based security thus utilizing the best of both worlds.
Try out KubeArmor
Clone Kubearmor from https://github.com/kubearmor/KubeArmor
Now you can protect your workloads in minutes using AccuKnox, it is available to protect your Kubernetes and other cloud workloads using Kernel Native Primitives such as AppArmor, SELinux, and eBPF.
Let us know if you are seeking additional guidance in planning your cloud security program.
Read more blogs from Cloud Security Category here.