Support for non orchestrated containers

Support for non-orchestrated containers

Other than containers running in Kubernetes, KubeArmor supports securing unorchestrated/non-orchestrated containerized workloads. Depending upon the host, both observability and policy enforcement is supported in this mode.

LSM specific behaviour

For enforcement, KubeArmor can use either of BPF LSM or AppArmor.

Enforcement using BPF LSM

Checkout this guide for enabling BPF LSM

Once your environment has BPF LSM enabled, enforcement for unorchestrated workloads is straight forward. You just need to create policies for nodes/containers with appropriate selectors and enforcement will work out of the box.

Allowed Label Selectors

• Any arbitrary labels added while running container
• kubearmor.io/container.name

NOTE

kubearmor.io/container.name is mutually exclusive with any other labels.

Enforcement using AppArmor

Host policy enforcement with AppArmor works out of the box however, certain unorchestrated environments like Docker have this limitation where an AppArmor profile must exist and the container must be run with it specified as an option in order for enforcement to work. Thus, it is recommended to use BPF LSM if possible. However, if due to some reason BPF LSM is not available, see the below steps.

Allowed Label Selectors

kubearmor.io/container.name is the only allowed label due to limitations of Docker with AppArmor.

Steps

For generating this template in Docker, either of the two paths might be taken:

1. First, create a KubeArmorPolicy for a the container you want to protect. This will lead to KubeArmor generating the template automatically. You can then update this policy and add new policies. Whenever you run the container, make sure you run it with the flag: --security-opt apparmor=kubearmor_<container_name> (replace <container_name> with the container's name).

2. You can also create the template based on the below template manually at /etc/apparmor.d/kubearmor_<container_name>.

   ## == Managed by KubeArmor == ##
   #include <tunables/global>
   
   ## == Dispatcher profile START == ##
   profile kubearmor_<container_name> flags=(attach_disconnected,mediate_deleted) {
           ## == PRE START == ##
           #include <abstractions/base>
   
           file,
           network,
           capability,
           ## == PRE END == ##
   
           ## == File/Dir START == ##
           ## == File/Dir END == ##
           ## == DISPATCHER START == ##
           ## == DISPATCHER END == ##
   
           ## == Network START == ##
           ## == Network END == ##
   
           ## == Capabilities START == ##
           ## == Capabilities END == ##
   
           ## == Native Policy START == ##
   
           ## == Native Policy END == ##
   
   
           ## == POST START == ##
           /lib/x86_64-linux-gnu/{*,**} rm,
   
           deny @{PROC}/{*,**^[0-9*],sys/kernel/shm*} wkx,
           deny @{PROC}/sysrq-trigger rwklx,
           deny @{PROC}/mem rwklx,
           deny @{PROC}/kmem rwklx,
           deny @{PROC}/kcore rwklx,
   
   
           deny mount,
   
   
           deny /sys/[^f]*/** wklx,
           deny /sys/f[^s]*/** wklx,
           deny /sys/fs/[^c]*/** wklx,
           deny /sys/fs/c[^g]*/** wklx,
           deny /sys/fs/cg[^r]*/** wklx,
           deny /sys/firmware/efi/efivars/** rwklx,
           deny /sys/kernel/security/** rwklx,
   
           ## == POST END == ##
   }
   ## == Dispatcher profile END == ##
   
   ## == FromSource per binary profiles START == ##
   ## == FromSource per binary profiles END == ##
   
   ## == Templates section START == ##
   

   To apply the template, run

   $ sudo apparmor_parser -r -W /etc/apparmor.d/kubearmor_<container_name>
   

   Now run your docker container with the --security-opt apparmor=kubearmor_<container_name> flag and policy enforcement with KubeArmor should work.

The first way will work for all of the cases, the second way might be useful in cases where the containers must run before KubeArmor.