Skip to main content

More Info:

allowPrivilegeEscalation lets a process gain more privileges than its parent. Blocking it limits in-container privilege escalation.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. List pods with allowPrivilegeEscalation: true (any machine with kubectl access)
    Save this list; you will need it to update the workloads.
  2. Review each affected workload and identify its owner (any machine with kubectl access)
    For each <namespace> <pod> <container> from step 1, get the owning controller (Deployment/DaemonSet/StatefulSet/Job/etc.):
    Use kind/name from .kind and .name to determine which resource/manifest you must change. If there is no ownerReference, the Pod is standalone and must be edited or recreated directly.
  3. Decide policy: namespace-level restriction vs. per-workload hardening (any machine with kubectl access)
    • If your cluster uses Pod Security Admission, consider labeling user namespaces with pod-security.kubernetes.io/enforce=restricted (or equivalent) only after confirming workloads can run without privilege escalation.
    • Otherwise, design or select an admission policy mechanism (e.g., Kyverno, OPA/Gatekeeper, custom admission webhook) that rejects Pods where any container has securityContext.allowPrivilegeEscalation: true or omits securityContext entirely.
      This benchmark control is MANUAL: you must choose the appropriate tooling and exceptions model for your environment; there is no single mandatory configuration.
  4. Harden workload manifests by setting allowPrivilegeEscalation: false (any machine with kubectl access)
    For each affected controller (Deployment, DaemonSet, etc.), edit its manifest (preferably in your Git/IaC repo) to set this on every container and initContainer:
    Apply the updated manifest:
    For standalone Pods generated without a controller, recreate them from an updated manifest containing the same change.
  5. (Optional) Introduce a rejecting admission policy for future Pods (any machine with kubectl access)
    After confirming critical workloads function with allowPrivilegeEscalation: false, configure your chosen admission controller to:
    • Deny any Pod in user namespaces where any container or initContainer has .securityContext.allowPrivilegeEscalation: true.
    • Optionally also deny if the field is missing, to force explicit false.
      Implement the policy using your platform’s recommended mechanism (e.g., Kyverno, Gatekeeper, PSA labels), then test in a non-production namespace before rolling out cluster-wide.
  6. Verify remediation (any machine with kubectl access)
    Re-run the audit and confirm no containers report is_compliant: false:
    Investigate and adjust any remaining is_compliant: false workloads or explicitly document them as approved exceptions.
On any machine with kubectl access:
  1. Create a baseline restricted admission policy for each user-workload namespace
    (example for namespace prod-apps; repeat per namespace with user workloads):
This uses the built-in “restricted” Pod Security Admission level, which disallows privilege escalation by default.
  1. For clusters/namespaces where you cannot (or do not want to) use PSA labels, create an explicit policy object.
    a) If your cluster still supports PodSecurityPolicy (legacy), apply:
Apply it:
Then bind it to your workloads’ service accounts (example for namespace prod-apps using the default service account; adjust as needed):
Apply it:
b) If your cluster uses another admission controller (e.g., Kyverno or OPA/Gatekeeper), define an equivalent rule that denies pods where .spec.containers[*].securityContext.allowPrivilegeEscalation == true. (This part is policy‑engine specific and must be created with its own CRDs; there is no generic kubectl-only object beyond what is shown above.)
  1. Update existing offending pods’ manifests so containers explicitly set allowPrivilegeEscalation: false.
    Example pod spec snippet you should ensure for each container:
Apply updated workload manifests using your normal deployment process, or:
  1. Verification (run on any machine with kubectl):