Description
AppArmor profiles restrict file access and certain operations for Linux containers. An appropriate profile on supporting nodes can reduce the impact of a compromised process. Absence of an annotation does not establish that no protection exists; check runtime defaults and the effective profile.
Potential impact
- Unnecessary file or system access can increase the impact of compromise.
- A missing or incompatible node profile can prevent container startup or required functionality.
Remediation
- Use RuntimeDefault or a reviewed Localhost profile on AppArmor-enabled nodes. For current Kubernetes, use securityContext.appArmorProfile through a provider configuration that supports it.
- Load Localhost profiles on all eligible nodes before scheduling the workload. Verify enforcement and denial logs and test required behavior.
Examples
These existing examples use the annotation mechanism from before Kubernetes 1.30. Use appArmorProfile with the current API. The local profile in the after example must already be loaded on the node; naming it does not install it. Use a maintained image for deployment.
Before
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "terraform-example"
}
spec {
container {
image = "nginx:1.7.9"
name = "example"
}
}
}
After
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "terraform-example"
annotations = {
"container.apparmor.security.beta.kubernetes.io/example" = "localhost/k8s-apparmor-example-allow-write"
}
}
spec {
container {
image = "nginx:1.7.9"
name = "example"
}
}
}
Explanation:
- Before: No explicit AppArmor annotation is present. Check the runtime’s effective default profile.
- After: A preloaded local profile is requested for container example. Review the profile’s rules and support as well.