Description
AppArmor restricts the files and certain system functions a Linux process can access. Without a required profile, an application compromise can allow a wider range of operations.
An absent annotation alone does not establish that AppArmor protection is absent. Check node support, runtime defaults and the profile actually applied.
Potential impact
- Access to unnecessary files or system functions may remain permitted.
- An incompatible or unloaded profile can prevent pod startup or normal operation.
Remediation
- On current Kubernetes, use the supported Pod or container securityContext.appArmorProfile to select RuntimeDefault or a required Localhost profile.
- Use nodes with AppArmor enabled and preload Localhost profiles on the nodes where pods will run. Test normal operations and denial logs, and manage other security-context controls as well.
Examples
The existing examples use the annotation mechanism from before Kubernetes 1.30; use appArmorProfile in current configurations. Define and load the after localhost profile separately on the nodes. Use a maintained image for deployment.
Before
yaml
resources:
pod:
type: kubernetes:core/v1:Pod
properties:
metadata:
annotations:
spec:
containers:
- image: nginx:1.14.2
name: nginx
After
yaml
resources:
pod:
type: kubernetes:core/v1:Pod
properties:
metadata:
annotations:
container.apparmor.security.beta.kubernetes.io/nginx: localhost/k8s-apparmor-example-allow-write
spec:
containers:
- image: nginx:1.14.2
name: nginx
Explanation:
- Before: No explicit AppArmor annotation is set. Inspect node and runtime settings to determine actual protection.
- After: A local profile is requested for the nginx container. Its name alone does not guarantee the restrictions or successful enforcement.