More Info:
Privileged containers have effectively unrestricted host access and can compromise the node. Block their admission in workload namespaces.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify workload namespaces and existing privileged pods
Run on: any machine with kubectl access -
Decide namespace policy scope and exceptions
Run on: administrator’s workstation (planning)- For each workload namespace, decide whether all privileged containers must be denied, or whether specific service accounts/namespaces need an exception (for example, infrastructure tooling).
- For any allowed exceptions, plan separate namespaces or dedicated service accounts with clearly documented justification, since this control is MANUAL and risk-based.
-
Create a baseline policy to deny privileged containers in a namespace
Run on: any machine with kubectl access
Example using the built-inPodSecurityadmission (Kubernetes ≥1.25). Replace<NAMESPACE>with an actual workload namespace and repeat for each one where privileged containers must be blocked.This label set enforces the “restricted” Pod Security level, which disallows privileged containers (securityContext.privileged: true) in that namespace. -
(If PodSecurity admission is not available) Apply a restrictive admission policy
Run on: any machine with kubectl access
If your cluster uses a policy engine (for example, Kubernetes-native PodSecurityPolicies on legacy clusters, or Gatekeeper/Kyverno), implement or tighten the admission policy for each workload namespace so that containers with.securityContext.privileged: trueare rejected. Example Kyverno ClusterPolicy (adjust names/namespaces to your environment before applying):Review this policy with your security team before applying, and tailor namespace lists and any needed exceptions. -
Refactor or remove existing privileged workloads
Run on: any machine with kubectl access
For each privileged pod identified in step 1 in user/workload namespaces:- Retrieve and edit the manifest:
- In
/tmp/<POD_NAME>.yaml, removesecurityContext.privileged: truefrom each container, or set it tofalse, and adjust capabilities/host access to meet functional needs without privilege. - Recreate the workload (ideally via its Deployment/DaemonSet/Job manifests rather than directly from a Pod):
- Where privileged access is truly required and accepted, move such workloads into a clearly designated, tightly controlled namespace and exempt it deliberately from the restrictive policy, with documented approval.
- Retrieve and edit the manifest:
-
Verify that privileged containers are no longer admitted
Run on: any machine with kubectl access- Attempt to create a test privileged pod in a protected workload namespace; it should be rejected:
- Confirm that any remaining running containers with
privileged: trueare only in explicitly approved namespaces (if any) and that user/workload namespaces are clean:
is_compliant: falseappear for regular workload namespaces. - Attempt to create a test privileged pod in a protected workload namespace; it should be rejected:
Using kubectl
Using kubectl
Automation
Automation

