More Info:
allowPrivilegeEscalation lets a process gain more privileges than its parent. Blocking it limits in-container privilege escalation.Risk Level
HighAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List pods with
allowPrivilegeEscalation: true(any machine with kubectl access)Save this list; you will need it to update the workloads. -
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.kindand.nameto determine which resource/manifest you must change. If there is no ownerReference, the Pod is standalone and must be edited or recreated directly. -
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: trueor omitssecurityContextentirely.
This benchmark control is MANUAL: you must choose the appropriate tooling and exceptions model for your environment; there is no single mandatory configuration.
- If your cluster uses Pod Security Admission, consider labeling user namespaces with
-
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. -
(Optional) Introduce a rejecting admission policy for future Pods (any machine with kubectl access)
After confirming critical workloads function withallowPrivilegeEscalation: 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.
- Deny any Pod in user namespaces where any container or initContainer has
-
Verify remediation (any machine with kubectl access)
Re-run the audit and confirm no containers reportis_compliant: false:Investigate and adjust any remainingis_compliant: falseworkloads or explicitly document them as approved exceptions.
Using kubectl
Using kubectl
On any machine with kubectl access:This uses the built-in “restricted” Pod Security Admission level, which disallows privilege escalation by default.Apply it:Then bind it to your workloads’ service accounts (example for namespace Apply it:b) If your cluster uses another admission controller (e.g., Kyverno or OPA/Gatekeeper), define an equivalent rule that denies pods where Apply updated workload manifests using your normal deployment process, or:
- Create a baseline restricted admission policy for each user-workload namespace
(example for namespaceprod-apps; repeat per namespace with user workloads):
- 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:
prod-apps using the default service account; adjust as needed):.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.)- Update existing offending pods’ manifests so containers explicitly set
allowPrivilegeEscalation: false.
Example pod spec snippet you should ensure for each container:
- Verification (run on any machine with kubectl):
Automation
Automation

