More Info:
Apply Security Context to Your Pods and ContainersRisk Level
MediumAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List pods that lack any pod-level securityContext
- Run on: any machine with kubectl access
- Record which namespaces/workloads (especially production or internet-facing) show up.
-
Inspect container-level securityContext usage in those pods
- For each
<namespace> <pod>pair from step 1, run:
- Flag containers where
.securityContextisnullor missing important fields such asrunAsNonRoot,runAsUser,readOnlyRootFilesystem,allowPrivilegeEscalation,capabilities, andseccompProfile.
- For each
-
Review security requirements with workload owners
- For each affected workload (Deployment/StatefulSet/DaemonSet/Job/CronJob), identify the controller:
- Discuss with owners whether the application truly needs root, writable root FS, added capabilities, or privilege escalation. Prefer the most restrictive settings that still allow the app to function.
-
Update the controller manifests to define appropriate securityContext
- Export the managing object manifest:
- Edit the file to add securityContext at pod spec and/or container level, for example under
spec.template.spec(for controllers) orspec(for standalone Pods), setting fields such as:runAsNonRoot: truerunAsUser: 1000readOnlyRootFilesystem: trueallowPrivilegeEscalation: falsecapabilities: { drop: ["ALL"] }seccompProfile: { type: "RuntimeDefault" }
- Apply the updated manifest:
-
Optionally enforce baseline via namespace or cluster policies
- If using Pod Security Admission, label namespaces to require at least baseline or restricted where appropriate:
- Or review/create PodSecurityPolicy (legacy), OPA Gatekeeper, or Kyverno policies to require reasonable securityContext defaults, tuned to your environment.
-
Re-verify pods and document accepted exceptions
- Re-run step 1 and 2 to confirm that high-value workloads now have explicit, restrictive securityContexts.
- For any pods that cannot comply (e.g., vendors requiring privileged containers), document the justification, scope them tightly (dedicated namespaces, node selectors, or policies), and ensure they are deliberately excluded or handled by your policy tooling.
Using kubectl
Using kubectl
- It appears in commands (2) or (3): no
securityContextat pod or container level. - It appears in command (4):
privileged=truecontainers are high risk and should only exist when strictly required. - It appears in command (5):
allowPrivilegeEscalationis not explicitlyfalse(eithertrueornull); default-allow may be unacceptable for sensitive workloads. - It appears in command (6):
runAsUser=0orrunAsUser=unset; running as root or relying on image defaults should be reviewed. - It appears in command (7):
readOnlyRootFilesystemisfalseornull; writable roots should be justified.
Automation
Automation

