Authorization bypass via AllowPrivilegeEscalation true in Kubernetes Pod securityContext

High Risk infrastructure-security
kubernetespod-securityprivilege-escalationauthorization-bypasscontainer-securitysetuidcapabilities

What it is

Kubernetes pods configured with allowPrivilegeEscalation set to true or not explicitly set to false enable container processes to gain more privileges than their parent process through setuid binaries, capabilities inheritance, or other privilege escalation mechanisms. This creates authorization bypass vulnerabilities that can lead to container escape and host compromise.

# VULNERABLE: Pod without privilege escalation controls
apiVersion: v1
kind: Pod
metadata:
  name: vulnerable-app
  namespace: production
spec:
  containers:
  - name: app
    image: app:v1.0.0
    # VULNERABLE: No securityContext - allows privilege escalation
    ports:
    - containerPort: 8080

# VULNERABLE: Deployment with privilege escalation enabled
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vulnerable-web
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: nginx:1.21
        securityContext:
          allowPrivilegeEscalation: true  # VULNERABLE
        ports:
        - containerPort: 80
# SECURE: Pod with privilege escalation prevented
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
  namespace: production
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    image: app:v1.0.0
    securityContext:
      allowPrivilegeEscalation: false  # SECURE
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      capabilities:
        drop: ["ALL"]
    ports:
    - containerPort: 8080

# SECURE: Deployment with strict security controls
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-web
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
      containers:
      - name: web
        image: nginx:1.25-alpine
        securityContext:
          allowPrivilegeEscalation: false  # SECURE
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          capabilities:
            drop: ["ALL"]
        ports:
        - containerPort: 8080

💡 Why This Fix Works

The vulnerable configurations either omit securityContext entirely or set allowPrivilegeEscalation to true, allowing container processes to gain additional privileges through setuid binaries or capability inheritance. The secure alternatives explicitly set allowPrivilegeEscalation: false in all container security contexts, combined with additional hardening measures like runAsNonRoot, dropping all capabilities, and using read-only root filesystems to prevent privilege escalation attacks.

Why it happens

Kubernetes pods deployed without explicit securityContext configuration at either the pod or container level. Without security context, containers use insecure defaults including allowing privilege escalation through setuid binaries and capability inheritance.

Root causes

Missing Security Context Configuration

Kubernetes pods deployed without explicit securityContext configuration at either the pod or container level. Without security context, containers use insecure defaults including allowing privilege escalation through setuid binaries and capability inheritance.

Insecure Default Escalation Setting

The allowPrivilegeEscalation field defaults to true when not explicitly set to false. This insecure default permits container processes to gain more privileges than their parent, enabling authorization bypass and container escape attempts.

Legacy Setuid Binary Dependencies

Applications rely on setuid/setgid binaries that require privilege escalation to function. Teams allow privilege escalation to maintain compatibility with legacy applications without refactoring to eliminate setuid dependencies.

Absent Pod Security Standards

Kubernetes clusters lack enforced Pod Security Standards (PSS) or Pod Security Policies. Without cluster-wide enforcement, there's no automatic prevention of insecure privilege escalation configurations in pod specifications.

Root Containers Without Restrictions

Containers running as root user without complementary privilege escalation controls. Running as root combined with privilege escalation enabled provides maximum attack surface for compromised applications to escalate beyond container boundaries.

Fixes

1

Disable Privilege Escalation in Security Context

Set allowPrivilegeEscalation: false explicitly in the securityContext of every container specification. This prevents container processes from gaining additional privileges through setuid binaries, no_new_privs kernel feature, or capability inheritance.

2

Apply Controls to All Container Types

Ensure security controls including allowPrivilegeEscalation: false are applied to all containers, initContainers, and ephemeral containers in pod specifications. Consistent application prevents bypass through less-scrutinized container types.

3

Enforce Pod Security Standards

Implement Kubernetes Pod Security Standards at the namespace or cluster level using Pod Security Admission. Enforce the 'restricted' standard which requires allowPrivilegeEscalation: false, providing automated policy enforcement.

4

Remove Setuid Binaries from Images

Audit container images and remove or disable setuid/setgid binaries that aren't absolutely necessary (e.g., sudo, su, passwd). Use RUN chmod commands in Dockerfiles to remove setuid bits, eliminating the need for privilege escalation.

5

Deploy Policy Enforcement Tools

Implement admission controllers like Kyverno, OPA Gatekeeper, or Pod Security Admission to automatically validate and enforce privilege escalation restrictions. Configure policies to reject or mutate pods that don't explicitly disable privilege escalation.

Detect This Vulnerability in Your Code

Sourcery automatically identifies authorization bypass via allowprivilegeescalation true in kubernetes pod securitycontext and many other security issues in your codebase.