Load and Enforce a Custom AppArmor Profile on a Kubernetes Node

Scenario

The security team wants proof that a custom AppArmor profile can be loaded on a node and actually enforced on a workload — not just attached as an unused annotation. A raw profile file has already been placed on node-01, but nothing has loaded it into the kernel yet.

cat /sys/module/apparmor/parameters/enabled

Task

1. On node-01, load the AppArmor profile located at /opt/apparmor-profiles/deny-write into the kernel so it runs in enforce mode.
2. Label node-01 with security=apparmor.
3. In a Namespace named sec-workloads, create a Deployment named hardened-web with:
   • image nginx:alpine
   • a container named web
   • the k8s-deny-write profile enforced on that container via securityContext
   • a nodeSelector that schedules the Pod onto the labeled node
4. The container is expected to fail to start because of the profile. Capture the Pod's logs and save them to /home/laborant/pod.log (run this from cplane-01).

⚒ Test Cases

securityContext:
  appArmorProfile:
    type: Localhost
    localhostProfile: <profile-name-as-loaded-in-the-kernel>

Understanding the Challenge

A raw AppArmor profile file already exists on node-01 at /opt/apparmor-profiles/deny-write, but nothing has loaded it into the kernel yet. Your job is to:

1. Load that profile into the kernel on node-01, in enforce mode.
2. Label node-01 so a Deployment can be scheduled onto it specifically.
3. Create a Deployment that runs nginx:alpine with the profile attached via securityContext.
4. Prove the profile is actually blocking writes by saving the crashing Pod's logs to a file.

Theory - What Is AppArmor?

AppArmor is a Linux Security Module (LSM), a piece of kernel-level mandatory access control (MAC). That's a very different model from the regular Unix permission bits (rwx, owner/group/other) you already know:

• Regular Unix permissions (DAC): controlled by the file's owner. If you own a file, you decide who can read/write/execute it, and root can override almost anything.
• AppArmor (MAC): a system-wide policy, not owned by any user, that restricts what a process is allowed to do, regardless of whether the process is running as root. A confined root process can still be denied access to a file it would otherwise be fully allowed to touch.

An AppArmor profile is a plain text file describing a named set of rules (file access, network access, capabilities, and more). A profile only takes effect once it's compiled and loaded into the kernel with apparmor_parser. Until that happens, the file on disk is just text; the kernel doesn't know it exists.

Once loaded, a profile runs in one of two relevant modes:

• enforce: violations are blocked and logged.
• complain: violations are only logged, never blocked (useful while developing a new profile).

You can see every profile the kernel currently knows about, and its mode, by reading a file under /sys/kernel/security/apparmor/.

Theory - How AppArmor Fits Into Kubernetes

This is the part that trips people up most: Kubernetes does not ship, distribute, or install AppArmor profiles for you. A profile is a node-level artifact. If you want a Pod to run under a custom profile, that exact profile must already be loaded into the kernel of whichever node the Pod lands on, before the Pod is scheduled there. In a real cluster this is usually handled by a DaemonSet, a node image build step, or config management; in this challenge, it's a manual step on node-01.

Since Kubernetes v1.30, a container requests a profile through securityContext.appArmorProfile, with three possible type values:

• RuntimeDefault: use the container runtime's built-in default profile.
• Localhost: use a specific profile already loaded on the node, identified by name via localhostProfile.
• Unconfined: run without any AppArmor confinement at all.

If a Pod requests a Localhost profile that isn't actually loaded on the node it gets scheduled to, the kubelet rejects the Pod outright (it never even starts) rather than silently ignoring the request. That's why loading the profile before creating the Deployment matters, and why the nodeSelector step matters too: it guarantees the Pod only ever lands on the one node where the profile actually exists.

Theory - Why a "Deny All Writes" Profile Breaks nginx

The profile staged on node-01 is intentionally blunt:

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

  file,

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

deny /** w denies write access to every single file path, recursively, system-wide, for any process confined by this profile. nginx:alpine needs to write several things the moment it starts: its PID file, and a handful of temp directories used for buffering client bodies and proxy responses. The very first of those writes gets denied, nginx exits with a non-zero status, and the container ends up in CrashLoopBackOff.

That crash is not a bug to fix; it's the proof the exercise is asking for. A profile that silently did nothing would be useless as evidence of enforcement.

Step 1 - Load the Profile on node-01

Inspect the staged file first:

cat /opt/apparmor-profiles/deny-write

#include <tunables/global>

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

  file,

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

The profile's internal name is k8s-deny-write (the word right after profile). That's the exact string you'll need later in the container's securityContext.

Load it into the kernel:

sudo apparmor_parser -q /opt/apparmor-profiles/deny-write

apparmor_parser compiles the profile and loads it in whatever mode the profile declares. Since this profile has no complain flag, it loads straight into enforce mode.

Confirm it's actually there:

sudo cat /sys/kernel/security/apparmor/profiles | grep k8s-deny-write

k8s-deny-write (enforce)

Step 2 - Label node-01

Switch to cplane-01 for every step from here on, since that's where kubectl is configured:

kubectl label node node-01 security=apparmor

node/node-01 labeled

Confirm it stuck:

kubectl get node node-01 --show-labels | grep security=apparmor

Step 3 - Create the Namespace and Deployment

kubectl create namespace sec-workloads

Now build the Deployment manifest. The three pieces that matter beyond a standard Deployment are the nodeSelector, the container name, and the securityContext.appArmorProfile block:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hardened-web
  namespace: sec-workloads
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hardened-web
  template:
    metadata:
      labels:
        app: hardened-web
    spec:
      nodeSelector:
        security: apparmor
      containers:
        - name: web
          image: nginx:alpine
          securityContext:
            appArmorProfile:
              type: Localhost
              localhostProfile: k8s-deny-write

Apply it:

kubectl apply -f hardened-web.yaml

Note the two things that must match exactly for this to work at all:

• nodeSelector.security must equal the label value you set in Step 2 (apparmor), so the Pod only ever lands on node-01.
• localhostProfile must equal the profile's internal name from Step 1 (k8s-deny-write), not the filename it was staged under.

Step 4 - Watch It Fail (as Expected) and Capture the Logs

kubectl get pods -n sec-workloads

NAME                            READY   STATUS             RESTARTS   AGE
hardened-web-6f8b9c7d5f-x2z9k   0/1     CrashLoopBackOff   3          90s

0/1 and CrashLoopBackOff are expected here. Grab the container's logs and save them to the required file:

kubectl logs -n sec-workloads deployment/hardened-web > /home/laborant/pod.log

cat /home/laborant/pod.log

nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2026/07/25 10:15:03 [emerg] 1#1: mkdir() "/var/lib/nginx/body" failed (13: Permission denied)

That "Permission denied" line, coming straight from nginx itself, is the proof the AppArmor profile is doing its job: the process tried to write a file and the kernel refused it before nginx could even initialize its own logging.

Step 5 - Confirm the Test Cases Pass

Test case 1, profile loaded and enforced on node-01:

sudo cat /sys/kernel/security/apparmor/profiles | grep -q "^k8s-deny-write (enforce)$" && echo OK

Test case 2, node label present (run from cplane-01):

kubectl get node node-01 -o jsonpath='{.metadata.labels.security}' | grep -q '^apparmor$' && echo OK

Test case 3, Deployment spec and scheduling correct:

kubectl get deployment hardened-web -n sec-workloads -o json | \
  jq -e '.spec.template.spec.containers[0].securityContext.appArmorProfile.localhostProfile == "k8s-deny-write"'

kubectl get pods -n sec-workloads -o jsonpath='{.items[0].spec.nodeName}'

node-01

Test case 4, log file saved with denial evidence:

grep -qi "permission denied" /home/laborant/pod.log && echo OK

Common Mistakes