Description
Pod and container security_context settings control the execution user, privilege escalation, filesystem access and capabilities. Relying only on environment defaults without required restrictions can give a workload broader privileges than intended.
An image, runtime, parent Pod configuration or admission policy may supply settings even without an explicit block. Review the effective values rather than treating block presence as sufficient.
Potential impact
- Containers may run with more privileges than they need.
- Different environment defaults can make security requirements inconsistent.
Remediation
- Configure security_context at supported levels and apply workload requirements such as non-root execution, minimal capabilities and a read-only root filesystem.
- Set run_as_non_root at Pod or container level and allow_privilege_escalation at container level. Container settings can override shared Pod fields, so verify the effective values.
- Match the image user and file/port permissions, then test startup and normal operation.
Examples
For var.non_root_image, supply a maintained image that runs with a numeric nonzero USER and supports the required file and port permissions. The existing nginx:1.7.9 uses root by default and is outdated, so it is unsuitable for the after configuration.
Before
resource "kubernetes_pod" "example" {
metadata {
name = "terraform-example"
}
spec {
container {
image = "nginx:1.7.9"
name = "example"
}
}
}
After
resource "kubernetes_pod" "example" {
metadata {
name = "terraform-example"
}
spec {
security_context {
run_as_non_root = true
}
container {
image = var.non_root_image
name = "example"
security_context {
allow_privilege_escalation = false
}
}
}
}
Explanation:
- Before: No explicit security context is present. Check the image and applied policies to determine actual privileges.
- After: The Pod requires non-root execution and the container restricts privilege escalation. Supply a compatible image separately.