Skip to main content

More Info:

Privileged containers have effectively unrestricted host access and can compromise the node. Block their admission in workload namespaces.

Risk Level

Critical

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify workload namespaces and existing privileged pods
    Run on: any machine with kubectl access
  2. 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.
  3. Create a baseline policy to deny privileged containers in a namespace
    Run on: any machine with kubectl access
    Example using the built-in PodSecurity admission (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.
  4. (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: true are 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.
  5. 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, remove securityContext.privileged: true from each container, or set it to false, 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.
  6. 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: true are only in explicitly approved namespaces (if any) and that user/workload namespaces are clean:
    Ensure that no lines with is_compliant: false appear for regular workload namespaces.
Example restrictive policy via a (legacy) PodSecurityPolicy-like admission controller (only if your cluster still uses it and you have the controller enabled):