KubeArmor is an open source solution Accuknox, where as 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, or 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.

MITRE TTPs in the context of K8 pods in a typical devsecops journey. KubeArmor can prevent run-time threats. 

Shown here are 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 wokloads  by using  security controls such as LSMs (Linux Security Modules) for confining and limiting them  process execution and file system access.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-block-untrusted-shell-execution
spec:
  tags : ["MITRE","D3fend","Execution","Unix Shell"] 
  message: "Deploy a container into an environment to facilitate execution or evade defenses"
  selector:
    matchLabels:
      app: testpod 
  process:
    severity: 2 # Higher severity for processes 
    matchPaths:
    - path: /bin/bash
    - path: /bin/sh
    - path: /usr/bin/bash
    - path: /usr/bin/env
    - path: /usr/bin/shell
    - path: /bin/ksh
    - path: /etc/init.d      
    - path: /dev/tty 
    - path: /bin/zsh
    - path: /bin/tcsh
    - path: /bin/csh
    action: Audit   
  file:
    severity: 10  # lowest severity for processes invoked as child process of bash
    matchPaths:
    - path: /bin/bash
    - path: /bin/sh
    - path: /usr/bin/bash
    - path: /usr/bin/env
    - path: /usr/bin/shell
    - path: /bin/ksh
    - path: /etc/init.d      
    - path: /dev/tty 
    - path: /bin/zsh
    - path: /bin/tcsh
    - path: /bin/csh
      fromSource:
      - path: /bin/bash
    action: Audit
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 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