It stops a process in the container from gaining more privileges than its parent process, for example by running a setuid binary. It sets the Linux no_new_privs flag on the container process. If you do not set the field, it defaults to true, which allows escalation, and the Restricted standard requires false.
The definition
The Kubernetes security context documentation defines allowPrivilegeEscalation as controlling whether a process can gain more privileges than its parent process, for example by executing a setuid binary. It directly controls the no_new_privs flag, though the value is inverted: if allowPrivilegeEscalation is true, no_new_privs is set to false.
Two facts that surprise people
- The default is permissive. If the field is not defined in a container's securityContext, it defaults to true. A manifest that says nothing allows escalation.
- It cannot be combined with some settings. The documentation says false is inconsistent with a container that runs privileged or has the CAP_SYS_ADMIN capability. Setting both will not give you what you expect.
What the standards say
The Restricted Pod Security Standard has a Privilege Escalation rule: privilege escalation, such as via set-user-ID or set-group-ID file mode, should not be allowed. The restricted fields are allowPrivilegeEscalation on containers, init containers and ephemeral containers, and the only allowed value is false.
How to set it
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
capabilities:
drop: ["ALL"]
Set it on every container, including init containers. The Kubernetes documentation examples show it inside a container's securityContext.
What can break
- Images that rely on a setuid helper, such as some tools that switch users at start, may stop working. Fix the image, not the setting.
- Containers run as privileged will conflict. Remove privileged first.
Test in a non production namespace using the warn mode of Pod Security Admission, then enforce. See our securityContext hardening checklist.
How to find workloads that do not set it
Because the default is true, a missing field is the finding. A policy check should fail when the field is absent, not only when it is true. Run that check on rendered manifests so Helm and Kustomize output is covered.
| Manifest says | Result |
|---|---|
| allowPrivilegeEscalation false | Escalation blocked |
| allowPrivilegeEscalation true | Escalation allowed |
| Field missing | Defaults to true, escalation allowed |
Quick check
If I do not set the field, is escalation blocked?
No. When it is not defined it defaults to true.
Does it replace running as non root?
No. They are separate controls. The Restricted standard asks for both.
Safeguard runs policies and gates on pull requests, so a failed rule can hold a merge, and its dependency and SBOM scanning covers the packages your infrastructure code pulls in. You can try a free scan at gold.safeguard.sh/scan.
Sources
- Configure a security context for a pod or container, Kubernetes documentation
- Pod Security Standards, Kubernetes documentation
Last reviewed: 19 October 2026.
