Skip to main content

More Info:

Apply Security Context to Your Pods and Containers

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. 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.
  2. Inspect container-level securityContext usage in those pods
    • For each <namespace> <pod> pair from step 1, run:
    • Flag containers where .securityContext is null or missing important fields such as runAsNonRoot, runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation, capabilities, and seccompProfile.
  3. 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.
  4. 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) or spec (for standalone Pods), setting fields such as:
      • runAsNonRoot: true
      • runAsUser: 1000
      • readOnlyRootFilesystem: true
      • allowPrivilegeEscalation: false
      • capabilities: { drop: ["ALL"] }
      • seccompProfile: { type: "RuntimeDefault" }
    • Apply the updated manifest:
  5. 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.
  6. 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.
How to interpret the outputA pod or container likely needs review when:
  • It appears in commands (2) or (3): no securityContext at pod or container level.
  • It appears in command (4): privileged=true containers are high risk and should only exist when strictly required.
  • It appears in command (5): allowPrivilegeEscalation is not explicitly false (either true or null); default-allow may be unacceptable for sensitive workloads.
  • It appears in command (6): runAsUser=0 or runAsUser=unset; running as root or relying on image defaults should be reviewed.
  • It appears in command (7): readOnlyRootFilesystem is false or null; writable roots should be justified.
These commands only surface candidates for review. A human must decide which securityContext fields are appropriate for each workload and then update the Pod templates (Deployments, DaemonSets, etc.) accordingly.

Additional Reading: