More Info:
Do not generally permit containers to be run with the securityContext.privileged flag set to true.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify all namespaces with user workloads (run on any machine with kubectl access):
Decide which namespaces should disallow privileged containers (typically all except core system namespaces like kube-system, kube-public, kube-node-lease, kube-admin equivalents).
-
Create a baseline policy that denies privileged containers (run once on any machine with kubectl access; use Pod Security Admission via labels as the default, plus optional PodSecurityPolicy or AdmissionPolicy if supported in your cluster). Example using Pod Security Admission “restricted” level:
Replace
NAMESPACE1 NAMESPACE2 NAMESPACE3with your chosen namespaces. -
(If PodSecurityPolicy is still in use in your cluster) Create a PSP that disallows privileged containers and a ClusterRole to use it (run on any machine with kubectl access):
-
(If PSP is in use) Bind the PSP to the service accounts that run user workloads in each target namespace (run on any machine with kubectl access):
-
Manually review and update existing workloads that currently request privileged containers to either:
- Remove
securityContext.privileged: true, or - Move them into carefully controlled namespaces with different admission policy and an explicit exception process.
For each non-compliant Deployment/DaemonSet/StatefulSet/etc., edit the manifest to removesecurityContext.privileged: trueand redeploy:Remove or setprivileged: falseunder the container’ssecurityContext, save, and let the controller recreate pods. - Remove
-
Verification (run on any machine with kubectl access):
Confirm that no lines show
is_compliant: falsefor namespaces where privileged containers should be minimized.
Using kubectl
Using kubectl
Automation
Automation

