Description
AppArmor restricts Linux container access to system resources such as files and networking. If the intended profile is not applied, a compromised application may have broader access. Omitted explicit configuration does not by itself prove there is no protection; check node support and the runtime’s default profile.
Potential impact
- Unnecessary system access can increase the impact of a compromise.
- An invalid profile name or unsupported node can prevent a container from starting.
Remediation
- With supported APIs, set securityContext.appArmorProfile to RuntimeDefault or a reviewed Localhost profile. Check Kubernetes version support before using historical annotations.
- Verify that AppArmor is enabled on the nodes, and preload custom profiles on every eligible node. Test actual profile application and required application behavior.
Examples
These examples compare the historical AppArmor annotation format. For new configurations, use the appArmorProfile field supported by the installed version.
Before
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
container.apparmor.security.beta.kubernetes.io/hello: dummy
spec:
containers:
- name: hello
image: busybox
command: ["sh", "-c", "sleep 1h"]
dummy is not a valid profile specification in the historical format. Check for startup rejection instead of assuming the container runs normally without protection.
After
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
container.apparmor.security.beta.kubernetes.io/hello: runtime/default
spec:
containers:
- name: hello
image: busybox
command: ["sh", "-c", "sleep 1h"]
The historical format requests the runtime default profile. Node AppArmor support and actual profile application still need verification.