AppArmor and seccomp Profiles for Pods
The largest piece of genuinely new ground between KCSA and CKS. This guide writes an AppArmor profile, loads it on a node, confines a Pod with it and proves the difference against an identical Pod - then does the same for seccomp, including how to check a running container rather than trusting its manifest.
System Hardening Guide 17 of 40 Advanced
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 22 min
AppArmor is configured through securityContext.appArmorProfile since 1.30; the old container.apparmor.security.beta.kubernetes.io annotation is deprecated. Both profiles must exist on every node the Pod might be scheduled to.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA7001 | 192.168.0.51 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA7001-NODE01 | 192.168.0.52 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this because it is the largest piece of genuinely new ground between KCSA and CKS. This matters because both controls are enforced by the kernel rather than by Kubernetes - the profile has to exist on the node before any Pod can name it.
- reading what the node already enforces, before touching anything
- writing an AppArmor profile and loading it
- confining a Pod with it, against an identical Pod that is not confined
- finding the other kernel control, and reading it out of
/proc - writing a seccomp profile that blocks four syscalls and leaves the rest alone
Before you start
-
What the node already enforces
-
Write a profile and load it
-
Confine a Pod with it
-
The other kernel control, and how to see it
-
A seccomp profile of your own