More Info:
SecurityContexts constrain the privileges and capabilities of pods and containers. Apply them to harden workloads.Risk Level
MediumAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify pods lacking a
securityContext- Run on: any machine with
kubectlaccess - Command:
- This lists pods where neither the pod nor any containers define a
securityContext.
- Run on: any machine with
-
Review current security settings for selected pods
- Pick a workload (preferably from a non-system namespace) from the list above.
- Command:
- Inspect
.spec.securityContextand each.spec.containers[].securityContextfor settings such asrunAsNonRoot,runAsUser,runAsGroup,readOnlyRootFilesystem,allowPrivilegeEscalation, andcapabilities.
-
Decide required hardening based on workload needs
- For each application/team owning the pods, determine:
- Whether the container can run as non-root (
runAsNonRoot: true, non-0runAsUser). - Whether it needs write access to root filesystem (if not,
readOnlyRootFilesystem: true). - Whether it needs extra Linux capabilities (drop all, then selectively add if required).
- Whether privilege escalation is needed (
allowPrivilegeEscalation: falseif not).
- Whether the container can run as non-root (
- Collect inputs from the app owners before changing manifests.
- For each application/team owning the pods, determine:
-
Update manifests to include appropriate
securityContext- Retrieve the controller manifest (Deployment/StatefulSet/Job/etc.):
- Edit
deployment-secctx.yamlto add security contexts, for example: - Apply the updated manifest:
- Repeat with other controllers (StatefulSets, DaemonSets, Jobs, CronJobs) rather than editing pods directly.
- Retrieve the controller manifest (Deployment/StatefulSet/Job/etc.):
-
Handle pods not managed by higher-level controllers
- List standalone pods (no ownerReferences):
- For any long-lived standalone pod you intend to keep, recreate it from a manifest that includes a
securityContext; avoid usingkubectl runwithout saving and hardening the YAML first.
- List standalone pods (no ownerReferences):
-
Verify that security contexts are now applied
- Re-run the initial check:
- Confirm that all non-exempt workloads (per your policy) no longer appear in the output and spot-check a few pods with
kubectl get pod -n NAMESPACE PODNAME -o yamlto ensure the intendedsecurityContextsettings are present.
- Re-run the initial check:
Using kubectl
Using kubectl
Using kubectl
1. List pods that have no pod-level securityContext
Run on: any machine with kubectl access.Any lines in the output are pods that do not define a pod-level
securityContext at all and should be manually reviewed. Lack of a pod-level securityContext is a red flag, especially for non-system namespaces.2. List containers without a container-level securityContext
Any line in the output shows a pod where one or more regular or init containers do not define a
securityContext. These containers must be reviewed to determine if explicit restrictions are needed (usually yes).3. Inspect a specific pod in detail
Replace<namespace> and <pod-name>..spec.securityContext.spec.containers[].securityContext.spec.initContainers[].securityContext
You see missing or overly-permissive fields such as:
- No
securityContextat all at pod or container level. runAsUser: 0orrunAsNonRoot: false(or not set where non-root is expected).privileged: true.allowPrivilegeEscalation: trueor not set.capabilities.addincluding dangerous capabilities (e.g.,SYS_ADMIN,NET_ADMIN).hostNetwork: true,hostPID: true,hostIPC: truewithout a clear, documented reason.readOnlyRootFilesystem: false(or missing) where a read-only root FS is possible.
4. Quickly surface some high‑risk patterns
a. Pods using privileged containersb. Pods allowing privilege escalation
c. Pods running containers as root (explicitly)
runAsUser: 0. Determining implicit root requires image review, not just kubectl.)5. Verification after you update manifests
After you manually adjust pod or deployment manifests to add appropriatesecurityContext settings, re-run:- The “no pod-level securityContext” command (step 1).
- The “containers without securityContext” command (step 2).
- Any specific high-risk pattern commands you are targeting (step 4).
- The previously flagged pods/containers no longer appear in the outputs, and
- A
kubectl get pod <pod> -n <ns> -o yamlshows the intendedsecurityContextfields applied.
Automation
Automation

