Skip to main content

Minimize The Admission Containers With Allow Privilege

More Info:​

Do not generally permit containers to be run with the allowPrivilegeEscalation flag set to true. Allowing this right can lead to a process running a container getting more rights than it started with.

Risk Level​

High

Address​

Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation​

Remediation​

Manual Steps

  1. List all namespaces and their pod security controls

    • On any machine with kubectl access: 
      kubectl get ns --show-labels
      kubectl get psp
      kubectl get psp -o yaml
    • Review whether namespaces are using PodSecurityPolicy (PSP, older clusters) or Pod Security Admission labels (e.g., pod-security.kubernetes.io/enforce=*). Note any namespaces without clear pod security controls.

  2. Identify workloads that explicitly allow privilege escalation

    • On any machine with kubectl access: 
      kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{"\n"}{end}'
      kubectl get pods -A -o yaml | grep -n "allowPrivilegeEscalation"
    • For each hit, inspect the full pod spec (or its controller) to see where allowPrivilegeEscalation: true is set: 
      kubectl get pod -n <namespace> <pod-name> -o yaml

  3. Review higher‑level controllers/manifests that generate these pods

    • On any machine with kubectl access, for namespaces with hits: 
      kubectl get deploy,sts,ds,job,cronjob -n <namespace> -o yaml | grep -n "allowPrivilegeEscalation"
    • For each controller that sets allowPrivilegeEscalation: true, decide whether it is strictly required (e.g., low‑level system daemon) or can be removed/changed. Document any business or technical justification where true is needed.

  4. Review or design policy to prevent unwanted privilege escalation

    • If using PSP (legacy):
      • On any machine with kubectl access: 
        kubectl get psp -o yaml
      • Confirm at least one PSP has .spec.allowPrivilegeEscalation omitted or set to false, and that it is actually bound via RBAC to the service accounts in the affected namespaces.
    • If using Pod Security Admission or another admission controller (OPA/Gatekeeper, Kyverno, etc.), review those policies to ensure they disallow allowPrivilegeEscalation: true except for explicitly approved namespaces/service accounts.

  5. Adjust manifests and/or policies where appropriate

    • For application workloads that do not need privilege escalation, edit their manifests (Git/IaC repo or kubectl edit as a temporary measure) to remove the field or set it to false, then redeploy: 
      # example for a deployment
      kubectl edit deploy -n <namespace> <deployment-name>
      # under securityContext or container.securityContext set:
      # allowPrivilegeEscalation: false
    • Update PSP or policy definitions so that, by default, containers cannot set allowPrivilegeEscalation: true, and only explicitly carved‑out components (if any) are allowed.

  6. Re‑verify the cluster state and policy coverage

    • On any machine with kubectl access: 
      # Check for remaining uses
      kubectl get pods -A -o yaml | grep -n "allowPrivilegeEscalation"
      # Confirm PSP/policies
      kubectl get psp -o yaml
      kubectl get ns --show-labels
    • Confirm that only intentionally approved workloads are able to run with allowPrivilegeEscalation: true, and that this is documented and justified.
Using kubectl

Using kubectl​

1. Identify pods that request allowPrivilegeEscalation: true​

Run on: any machine with kubectl access.

kubectl get pods -A -o json | \
  jq -r '
  .items[]
  | .metadata as $m
  | (.spec.initContainers[]? + .spec.containers[]?)
  | select(.securityContext.allowPrivilegeEscalation == true)
  | "\($m.namespace) \($m.name) \(.name) true"
  ' | column -t

What indicates a problem:

  • Any line in the output shows a pod/container explicitly setting allowPrivilegeEscalation to true.
  • These should be reviewed; in most workloads this should be false or unset.

If you don’t have jq:

kubectl get pods -A -o yaml | \
  grep -C3 -n "allowPrivilegeEscalation: true"

Problem indication:

  • Any occurrence of allowPrivilegeEscalation: true in container securityContext blocks.

2. Check pods that omit allowPrivilegeEscalation (rely on defaults)​

Cluster defaults may allow escalation if not explicitly denied. List all pods and inspect security context details:

kubectl get pods -A -o json | \
  jq -r '
  .items[]
  | .metadata as $m
  | (.spec.initContainers[]? + .spec.containers[]?)
  | {
      ns: $m.namespace,
      pod: $m.name,
      container: .name,
      sc: .securityContext
    }
  ' | less

What indicates a potential problem:

  • Containers whose securityContext is null or does not contain allowPrivilegeEscalation: false, and you know there is no cluster-wide policy (e.g., PSP, PodSecurity admission, or other policy engine) enforcing allowPrivilegeEscalation=false.
  • These need human review: either set allowPrivilegeEscalation: false in pod specs or rely on a clear cluster policy.

3. Review namespace-level posture​

List all pods per namespace where escalation is explicitly allowed:

kubectl get pods -A -o json | \
  jq -r '
  .items[]
  | .metadata as $m
  | (.spec.initContainers[]? + .spec.containers[]?)
  | select(.securityContext.allowPrivilegeEscalation == true)
  | "\($m.namespace)"
  ' | sort | uniq -c | sort -nr

What indicates a problem:

  • Namespaces with counts > 0 have workloads explicitly allowing privilege escalation.
  • Focus review on those namespaces; they may need policy tightening and manifest changes.

4. Review pod specs in problematic namespaces​

For a specific namespace you want to examine (replace TARGET_NAMESPACE):

kubectl get pods -n TARGET_NAMESPACE -o yaml | \
  sed -n '/securityContext:/,/^\s*image:/p' | \
  sed -n '/name:/,/^\s*image:/p' | \
  grep -C3 "allowPrivilegeEscalation"

What indicates a problem:

  • Containers in that namespace with allowPrivilegeEscalation: true.
  • Containers lacking an explicit allowPrivilegeEscalation: false where you expect strict hardening.

5. Verification after you make policy/manifest decisions​

Once you have updated policies/manifests and redeployed:

kubectl get pods -A -o json | \
  jq -r '
  .items[]
  | .metadata as $m
  | (.spec.initContainers[]? + .spec.containers[]?)
  | select(.securityContext.allowPrivilegeEscalation == true)
  | "\($m.namespace) \($m.name) \(.name) true"
  ' | column -t

Verification criteria:

  • For namespaces you want hardened, the above command should return no lines.
  • Any remaining entries must be explicitly accepted exceptions after human review.
Automation
#!/usr/bin/env bash
# Run on: any machine with kubectl access
# Purpose: Report pods/containers that allow privilege escalation

set -euo pipefail

echo "=== Cluster-wide allowPrivilegeEscalation audit ==="
echo "Time: $(date)"
echo

# 1) Show any PodSecurityPolicy objects with allowPrivilegeEscalation not explicitly false
echo "== PodSecurityPolicy review (if PSP is enabled) =="
kubectl get podsecuritypolicies.policy -o json 2>/dev/null \
  | jq -r '
    .items[]
    | {name: .metadata.name, allowPrivilegeEscalation: .spec.allowPrivilegeEscalation}
  ' 2>/dev/null || echo "No PodSecurityPolicy objects found or PSP not enabled"
echo

# 2) List all pods where any container sets allowPrivilegeEscalation=true
echo "== Pods with containers that allow privilege escalation =="
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | . as $pod
    | [
        # normal containers
        ($pod.spec.containers[]? | {type:"container", name:.name, ape:(.securityContext.allowPrivilegeEscalation // "unset")}),
        # init containers
        ($pod.spec.initContainers[]? | {type:"initContainer", name:.name, ape:(.securityContext.allowPrivilegeEscalation // "unset")})
      ]?
    | map(select(.ape == true))
    | select(length > 0)
    | .[] as $c
    | "\($pod.metadata.namespace)\t\($pod.metadata.name)\t\($c.type)\t\($c.name)\tallowPrivilegeEscalation=\($c.ape)"
  ' | column -t
echo

# 3) Summarize counts per namespace
echo "== Summary count of problematic containers per namespace =="
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | . as $pod
    | [
        ($pod.spec.containers[]? | {ape:(.securityContext.allowPrivilegeEscalation // "unset")}),
        ($pod.spec.initContainers[]? | {ape:(.securityContext.allowPrivilegeEscalation // "unset")})
      ]?
    | map(select(.ape == true))
    | select(length > 0)
    | $pod.metadata.namespace
  ' \
  | sort \
  | uniq -c \
  | awk '{printf "namespace=%s\tproblematic_containers=%d\n",$2,$1}'

Explanation of output indicating a problem:

  • In the “PodSecurityPolicy review” section, any PSP where allowPrivilegeEscalation is true or null/missing should be reviewed; per the benchmark, it should be omitted or set to false.
  • In the “Pods with containers that allow privilege escalation” section:
    • Any line shown is a problem: that container has allowPrivilegeEscalation=true.
    • The columns are: NAMESPACE POD TYPE CONTAINER_NAME allowPrivilegeEscalation=true.
  • In the “Summary count” section:
    • Any namespace listed has at least one container with allowPrivilegeEscalation=true; higher counts indicate higher remediation priority.

Use this report to drive a manual review of the workloads and policies; changes must be made per-application/manifests and cannot be safely auto-fixed.

Additional Reading:​