Allowing process privilege escalations exposes the Pod to attacks that exploit setuid binaries. This field directly controls whether the `no_new_privs` flag is set in the container process. + When this flag is enabled, binaries configured with setuid or setgid bits cannot change their runtime uid or gid: Potential attackers must rely on other privilege escalation techniques to successfully operate as root on the Pod. Depending on how resilient the Kubernetes cluster and Pods are, attackers can extend their attack to the cluster by compromising the nodes from which the cluster started the Pod. The `allowPrivilegeEscalation` field should not be set to true unless the Pod's risks related to setuid or setgid bits have been mitigated. == Ask Yourself Whether * This Pod is accessible to people who are not administrators of the Kubernetes cluster. * This Pod contains binaries with setuid or setgid capabilities. There is a risk if you answered yes to all of these questions. == Recommended Secure Coding Practices Disable privilege escalation. == Sensitive Code Example [source,yaml] ---- apiVersion: v1 kind: Pod metadata: name: example spec: containers: - name: web image: nginx ports: - name: web containerPort: 80 protocol: TCP securityContext: allowPrivilegeEscalation: true # Sensitive ---- == Compliant Solution [source,yaml] ---- apiVersion: v1 kind: Pod metadata: name: example spec: containers: - name: web image: nginx ports: - name: web containerPort: 80 protocol: TCP securityContext: allowPrivilegeEscalation: false ---- == See * CWE - https://cwe.mitre.org/data/definitions/284[CWE-284 - Improper Access Control] * https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt[Linux Kernel Archives, no_new_privs] - Official docs ifdef::env-github,rspecator-view[] ''' == Implementation Specification (visible only on this page) === Message Make sure that enabling privilege escalation is safe here. === Highlighting Highlight `allowPrivilegeEscalation: true`. endif::env-github,rspecator-view[]