Description
securityContext defines permissions and execution conditions for Pods and containers. Omitting it relies on defaults from the image, runtime and admission policies. Omission alone does not prove that all protection is absent, but it makes required protections harder to verify. Adding an empty securityContext does not establish those protections either.
Potential impact
- Required controls such as non-root execution or prevention of privilege escalation may be absent.
- Inconsistent execution settings can leave isolation weaker than expected during a compromise.
Remediation
- Specify the required securityContext at Pod and individual container level, using fields supported at each level. Review execution identity, allowPrivilegeEscalation, readOnlyRootFilesystem and Linux capabilities.
- Check whether container settings override shared Pod settings and verify the effective values. Align image users, file permissions and required writable paths, then test startup and normal operation.
Examples
Replace the illustrative image with a verified actual image. It must support UID 1000; paths needing writes require separate volumes and suitable permissions.
Before
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
Pod and container execution conditions are not specified, so defaults apply.
After
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
securityContext:
runAsUser: 1000
containers:
- name: app
image: images.my-company.example/app:v4
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
The Pod specifies UID 1000, and the container prevents privilege escalation and uses a read-only root filesystem. Other required security controls still need separate review.