AppArmor in Kubernetes Linux Security Modules

Linux security modules are kernel extensions that allow the kernel to enforce certain security policies on the system. One such security module is AppArmor, which is a mandatory access control system that allows system administrators to specify which programs can access which resources on the system. It is typically used to protect against malicious software or unauthorized access to system resources. AppArmor operates by assigning profiles to programs, which define the resources that the program is allowed to access. When a program attempts to access a resource that is not listed in its profile, AppArmor will block the access and log the event. This can help to prevent security breaches and improve the overall security of the system.

So what does that look like in our terminal well opening up a fresh kubernetes cluster running 1.26 on killercoda shows us

aa-status

Output should look something similar of this and should state apparmor module is loaded

So this is what is enabled on the node understand that as well you’d have to check the other nodes you provision in this status as well never assume always verify.

For applying a profile that you want added to this list you’ll use the following syntax

apparmor_parser -q <profile>
 #include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /** w,
}

If you need to check if AppArmor is enabled run the command below and look for a Y

cat /sys/module/apparmor/parameters/enabled
Y

Reference for apparmor parser can be found here

https://manpages.ubuntu.com/manpages/kinetic/en/man8/apparmor_parser.8.html

To verify its loaded run the same command that we ran earlier

aa-status

While this is touching a small portion of what the use of the module this shows you that native controls in the OS such as AppArmor are able to be loaded/used to restrict usage in our pods. For purposes such as how this changes your YAML Files it will appear as below

apiVersion: v1
kind: Pod
metadata:
  name: pod
  annotations:
    # tells kubernetes api to apply apparmor profile
    container.apparmor.security.beta.kubernetes.io/nginx: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
  - name: nginx
    image: nginx:1.22.1-alpine
    command: ["sh", "-c", "echo 'Running AppArmor....!!' && sleep 1h"]

This is one area of focus a part of the CKS objectives but also wanted to take a look at how this would apply in a YAML format.

Native controls especially rules are a backstop so apply these as restrictive as nature to minimize the risk of escalation from images that could have no confinements declared.

In a Kubernetes cluster, security is important because it is a multi-tenant environment where multiple applications and users share the same underlying infrastructure. Linux security modules allow the kernel to enforce security policies that apply to all programs running on the system, regardless of which user or application is running them. This is especially important in a Kubernetes cluster, where there may be many different applications and users interacting with the cluster at any given time. By using Linux security modules, the cluster can enforce security policies that protect against unauthorized access to resources and prevent security breaches.