The no-new-privileges setting stops a process in a container, and its children, from gaining more privileges than it started with, for example by running a setuid binary. In Docker you set it with a security option. In Kubernetes the matching field is allowPrivilegeEscalation set to false.
What it blocks
Some programs on a Linux system are marked so that they run with the privileges of their owner, often root. Classic examples are tools like su and sudo. If an attacker has a shell as a normal user inside a container and finds one of these with a weakness, it can be a path to root.
The Docker run reference describes the no-new-privileges option as disabling container processes from gaining new privileges. It notes the effect: privilege-raising commands such as su and sudo stop working. It also says seccomp filters are applied after privileges are dropped, which can allow a more restrictive filter set.
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 adds that when the value is true, the no_new_privs flag is false, and that if you do not define it, it defaults to true.
That default is worth noticing. If you write no security context, escalation is allowed.
How to set it
Docker:
docker run --security-opt no-new-privileges myimage
Kubernetes:
securityContext:
allowPrivilegeEscalation: false
The Kubernetes page also notes that allowPrivilegeEscalation set to false cannot be combined with a privileged container or one that has the CAP_SYS_ADMIN capability. If you try, the combination is rejected, which is a sign the workload asks for too much.
What it does not do
- It does not remove root. If the process already runs as root, there is nothing to escalate to. Combine it with a non-root user.
- It does not drop capabilities. Capabilities granted at start still apply. Drop the ones you do not need.
- It does not stop kernel exploits. A bug in the kernel is a different path.
- It does not limit network or file access the process already has.
It is a small switch that closes one well-known route, which is why the OWASP cheat sheet lists it as its own rule next to dropping capabilities.
Side effects to test
Anything that relies on a setuid helper at runtime will fail. That includes images that call sudo in an entrypoint script, or tools that change user at start. The usual fix is to run the whole container as the final user from the start and remove the helper, which also makes the image smaller.
Containers that use file capabilities on binaries can also behave differently. Test before rolling out widely.
A short rollout plan
- List workloads with no security context.
- Set the field in a test environment and watch for start-up errors.
- Fix entrypoints that call sudo or su.
- Add a policy check for new workloads.
Safeguard's policies and gates can encode a rule like this as part of review, and a free scan shows what is in an image, including setuid-related tooling you might remove.
Quick check
Should every container set it?
For most application containers, yes. Exceptions are rare tools that deliberately need a setuid helper, and those are worth questioning.
Is it the same as running non-root?
No. Non-root sets who the process is. No-new-privileges stops that process from becoming someone more powerful.
Sources
- Docker container run reference
- Kubernetes: configure a security context
- OWASP Docker Security Cheat Sheet
Last reviewed: 19 October 2026.
