Hands-on Lab·Certified Kubernetes Security Specialist
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 - tunnel/VXLAN, with Hubble relay and UI
- Host OSUbuntu 26.04 LTS, kernel 7.0.0-29
- Built withkubeadm v1.36.3 - podSubnet 10.244.0.0/16, serviceSubnet 10.96.0.0/12
- TimeAbout 22 min
- Reviewed25 August 2026
Written against the versions above. 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.
| 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 |
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