> ## Documentation Index > Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Minimize The Admission Containers With Allow Privilege Escalation ### 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 1. **List all namespaces and their pod security controls** * On any machine with kubectl access: ```sh theme={null} 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: ```sh theme={null} 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: ```sh theme={null} kubectl get pod -n -o yaml ``` 3. **Review higher‑level controllers/manifests that generate these pods** * On any machine with kubectl access, for namespaces with hits: ```sh theme={null} kubectl get deploy,sts,ds,job,cronjob -n -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: ```sh theme={null} 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: ```sh theme={null} # example for a deployment kubectl edit deploy -n # 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: ```sh theme={null} # 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 #### 1. Identify pods that request `allowPrivilegeEscalation: true` Run on: any machine with kubectl access. ```bash theme={null} 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`: ```bash theme={null} 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: ```bash theme={null} 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: ```bash theme={null} 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`): ```bash theme={null} 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: ```bash theme={null} 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. ```bash theme={null} #!/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: * [https://kubernetes.io/docs/concepts/security/pod-security-standards/](https://kubernetes.io/docs/concepts/security/pod-security-standards/)