More Info:
Apply Security Context to Your Pods and ContainersRisk Level
MediumAddress
SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS GKE
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List pods and identify those missing securityContext
- Run on: any machine with
kubectlaccess
- This lists pods with no pod-level or container-level securityContext defined.
- Run on: any machine with
-
Inspect security context details for a specific pod
- Run on: any machine with
kubectlaccess
- Review which settings (runAsUser, runAsNonRoot, readOnlyRootFilesystem, capabilities, privileged, hostNetwork, hostPID, hostIPC, seccompProfile, etc.) are missing or overly permissive.
- Run on: any machine with
-
Review workload owners (Deployments, etc.) for missing or weak security contexts
- Run on: any machine with
kubectlaccess
- Identify templates that lack securityContext or set privileged: true, allow privilege escalation, broad capabilities, or host namespaces/paths.
- Run on: any machine with
-
Decide required security context based on app needs and org policy
- For each workload identified in steps 1–3, review with the app owner whether it can:
- Run as non-root (runAsNonRoot: true, runAsUser: non-0 UID, runAsGroup)
- Use a read-only root filesystem
- Drop all capabilities and add back only specific required ones
- Avoid privileged: true and avoid hostPath, hostNetwork, hostPID, hostIPC where possible
- Refer to your org’s baseline and the CIS Google Container-Optimized OS Benchmark to choose appropriate defaults.
- For each workload identified in steps 1–3, review with the app owner whether it can:
-
Update manifests to add or tighten securityContext
- Run on: any machine with
kubectlaccess - Export current manifest, edit locally, then apply:
- In
/tmp/"$WORKLOAD".yaml, under.spec.template.specadd or adjust, for example:
- Then apply:
- Run on: any machine with
-
Re-verify that pods now have appropriate security contexts
- Run on: any machine with
kubectlaccess
- Confirm that critical workloads are no longer listed, and spot-check updated pods with:
- Run on: any machine with
Using kubectl
Using kubectl
POD_SCis<none>for most pods, andCONTAINERS_SCis<none>or{}(empty) for most containers.
This shows security context is largely not defined.
.spec.securityContext(pod-level).spec.containers[*].securityContext.spec.initContainers[*].securityContext(if present)
- Missing
securityContextblocks entirely. - Present but empty securityContext
{}with no meaningful fields. - Risky settings, for example:
runAsUser: 0orrunAsNonRoot: falseprivileged: trueallowPrivilegeEscalation: true- Broad
capabilities.add(e.g.,SYS_ADMIN,NET_ADMIN).
runAsUser=is empty andrunAsNonRoot=is empty/false (likely root).privileged=trueorallowPrivilegeEscalation=truewithout a strong justification.
- Any application or multi-tenant workload appears in this list without a clear, documented need to be privileged.
- Application pods listed here generally need stricter
securityContext(e.g.,allowPrivilegeEscalation: false) unless there is a specific requirement.
These commands only surface current state. A human must decide, per workload, which security context fields to add or tighten based on application needs and your organization’s security policy.
Automation
Automation

