AppArmor in Kubernetes

👋 Hi! I’m Bibin Wilson. In each edition, I share practical tips, guides, and the latest trends in DevOps and MLOps to make your day-to-day DevOps tasks more efficient. If someone forwarded this email to you, you can subscribe here to never miss out!

In yesterday's edition, we looked at what AppArmor is and how it works.

In today's edition, we will look at how to use AppArmor profiles with Kubernetes with a hands-on example.

You can give it a try in your development cluster.

Enabling Apparmor Profile on Worker Nodes

To make use of an AppArmor profile for pods, the profiles must be enabled on all the worker nodes. Otherwise, if a pod using a profile lands on a node without a profile, it won't get applied

There is no direct option to apply profiles.

Basically, the VM image used for worker nodes should be backed with all the AppArmor profiles as per the security requirements.

If you need to add a profile, you must redeploy the nodes with the new profiles.

For this example, I will add a profile to a worker node and enable it

AppArmor Profile to Deny Writes in Specific Directories

Let's start by creating a custom AppArmor profile on Kubernetes node(s) that will block write operations to specific directories.

In this example, we'll restrict write access to /etc and /var/lib inside the container.

As you know, AppArmor profiles are text files that typically reside in /etc/apparmor.d/.

Create a profile at /etc/apparmor.d/deny-etc-varlib-write

#include <tunables/global>
profile deny-etc-varlib-write flags=(attach_disconnected) {
  #include <abstractions/base>
  file,
  # Deny write operations in /etc/ and /var/lib/ (and all subdirectories)
  deny /etc/** w,
  deny /var/lib/** w,
}

The deny /etc/** w, and deny /var/lib/** w, rules deny any file write (w) operations under /etc or /var/lib and their subdirectories.

Save this profile file on each node in your cluster (for example, as /etc/apparmor.d/deny-etc-varlib-write).

Ensuring each node has the profile is important because Kubernetes does not automatically propagate AppArmor profiles to nodes.

If a Pod is scheduled to a node where the profile is not loaded, the Pod will fail to start with an AppArmor error​

Load the AppArmor Profile

Once the profile file is in place, load it into the kernel using the apparmor_parser tool.

sudo apparmor_parser -r /etc/apparmor.d/deny-etc-varlib-write

This command parses and loads the profile into the kernel (the -r flag will replace any existing profile with the same name).

You can verify the profile is loaded by checking AppArmor status.

sudo aa-status | grep deny-etc-varlib-write

Kubernetes Pod with the AppArmor Profile

Now that the profile is loaded on the nodes, you can create a Pod (or Deployment) that uses this AppArmor profile.

We do this by adding it to the security context of the pod under the appArmorProfile parameter, as shown below.

apiVersion: v1
kind: Pod
metadata:
  name: apparmor-demo
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: deny-etc-varlib-write
  containers:
  - name: nginx
    image: busybox:latest
    command: [ "sh", "-c", "sleep 3000" ]

Once you deploy the pod, you can check the active profile of the pod using the following command. It should output the profile name in enforce mode, as shown below.

$ kubectl exec -it apparmor-demo -- cat /proc/1/attr/current

deny-etc-varlib-write (enforce)

Testing and Validating the AppArmor Policy

Now let's test that our AppArmor profile is doing its job by trying to write to both an allowed location and a restricted location from within the pod.

Here is the output.

As you can see, any writes to /etc are blocked.

This happens because our AppArmor profile denies writes to /etc, causing the operation to fail with a "Permission denied" error.

AppArmor in Real-World Scenarios

You don't usually see AppArmor implemented in regular projects.

It is mainly used in security-sensitive environments.

For example, it is used in the banking sector or in applications that are under very strict security compliance requirements.