Skip to main content

Minimize The Admission Containers With

More Info:​

Do not generally permit containers to be run with the hostNetwork flag set to true.

Risk Level​

High

Address​

Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS AKS
  • CIS Critical Security Controls v8
  • 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. Identify user-workload namespaces and current Pod Security labels

    • Run on: any machine with kubectl access
    kubectl get ns --show-labels
    • Decide which namespaces are user-workload (exclude kube-system, kube-public, kube-node-lease, and any other infra-only namespaces).
    • Note existing pod-security.kubernetes.io/* labels on those namespaces, if any.

  2. Review current use of allowPrivilegeEscalation in running workloads

    • Run on: any machine with kubectl access
    # Pods explicitly setting allowPrivilegeEscalation: true
    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, .securityContext.allowPrivilegeEscalation]
      | @tsv
    '
    • If jq is not available, inspect suspicious pods manually:
    kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep -A5 -n "securityContext"
    • Decide which uses are strictly required (for example, known privileged system components in a dedicated namespace).

  3. Decide the target Pod Security level per namespace

    • For most user namespaces, plan to enforce restricted, which disallows privilege escalation.
    • For namespaces that legitimately need privilege escalation (if any), either:
      • Keep them at baseline/unlabeled and enforce controls via other mechanisms (e.g., admission controllers), or
      • Create a dedicated namespace for those exceptional workloads and restrict who can deploy there.

  4. Apply or tighten Pod Security labels on namespaces

    • Run on: any machine with kubectl access
    • Enforce restricted policies on specific user-workload namespaces:
    kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/enforce=restricted
    • Optionally, add a warning level of baseline on all namespaces to surface issues without blocking:
    kubectl label --overwrite ns --all pod-security.kubernetes.io/warn=baseline
    • Repeat as appropriate for each namespace based on the decisions from step 3.

  5. Adjust or migrate workloads that violate the new policy

    • For pods flagged in step 2 that are not truly exceptional, update their manifests to either remove allowPrivilegeEscalation or set it to false, then redeploy:
    # Example pattern for Deployment
    kubectl edit deploy DEPLOYMENT_NAME -n NAMESPACE
    • In the editor, under each containers[].securityContext, ensure:
    allowPrivilegeEscalation: false
    • If a workload legitimately requires allowPrivilegeEscalation: true, ensure it runs only in the designated exception namespace decided in step 3.

  6. Verify enforcement and absence of new violating pods

    • Confirm namespace labels:
    kubectl get ns --show-labels | grep pod-security.kubernetes.io
    • Attempt to create a test pod with allowPrivilegeEscalation: true in a restricted namespace; it should be rejected:
    cat << 'EOF' | kubectl apply -n NAMESPACE -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: test-ape
    spec:
      containers:
      - name: c
        image: busybox
        command: ["sh", "-c", "sleep 3600"]
        securityContext:
          allowPrivilegeEscalation: true
    EOF
    • Verify no running pods in user-workload namespaces have allowPrivilegeEscalation: true:
    kubectl get pods -A -o json | jq -r '
      .items[]
      | select(.metadata.namespace != "kube-system"
               and .metadata.namespace != "kube-public"
               and .metadata.namespace != "kube-node-lease")
      | .metadata as $m
      | (.spec.initContainers[]?, .spec.containers[]?)
      | select(.securityContext.allowPrivilegeEscalation == true)
      | [$m.namespace, $m.name, .name]
      | @tsv
    '
Using kubectl
# 1) List all namespaces and show Pod Security admission labels
# Run on: any machine with kubectl access
kubectl get ns -o custom-columns=NAME:.metadata.name,ENFORCE:".metadata.labels.pod-security\.kubernetes\.io/enforce",WARN:".metadata.labels.pod-security\.kubernetes\.io/warn"

# 2) Inspect only namespaces that do NOT enforce "restricted"
# (these are the primary candidates for allowing privilege escalation)
kubectl get ns \
  -o custom-columns=NAME:.metadata.name,ENFORCE:".metadata.labels.pod-security\.kubernetes\.io/enforce" \
  --no-headers | awk '$2 != "restricted" {print $1}'

# 3) For a specific namespace, view all PodSecurity labels
NAMESPACE=default
kubectl get ns "$NAMESPACE" --show-labels

# 4) Check all running pods in a namespace for allowPrivilegeEscalation=true
# This surfaces concrete examples to review
NAMESPACE=default
kubectl get pods -n "$NAMESPACE" -o json | \
  jq -r '
    .items[]
    | {pod: .metadata.name,
       containers: ([.spec.containers[], (.spec.initContainers // [])[]?]
         | map({name, allowPrivilegeEscalation: (.securityContext.allowPrivilegeEscalation // "unset")})
       )}
  '

# 5) Narrow to only containers where allowPrivilegeEscalation is explicitly true
NAMESPACE=default
kubectl get pods -n "$NAMESPACE" -o json | \
  jq -r '
    .items[]
    | .metadata.name as $pod
    | ([.spec.containers[], (.spec.initContainers // [])[]?]
       | map(select(.securityContext.allowPrivilegeEscalation == true)
             | {name, allowPrivilegeEscalation: .securityContext.allowPrivilegeEscalation}))
    | select(length > 0)
    | {pod: $pod, containers: .}
  '

# 6) (Optional) Cluster-wide search for allowPrivilegeEscalation=true in all pods
kubectl get pods -A -o json | \
  jq -r '
    .items[]
    | .metadata.namespace as $ns
    | .metadata.name as $pod
    | ([.spec.containers[], (.spec.initContainers // [])[]?]
       | map(select(.securityContext.allowPrivilegeEscalation == true)
             | {name, allowPrivilegeEscalation: .securityContext.allowPrivilegeEscalation}))
    | select(length > 0)
    | {namespace: $ns, pod: $pod, containers: .}
  '

How to interpret the output

  • From command 1:
    • Namespaces where ENFORCE is empty or not restricted may be too permissive and should be reviewed.
  • From command 2:
    • All listed namespaces are not enforcing restricted; these are candidates where policies may not be preventing allowPrivilegeEscalation=true.
  • From commands 4–6:
    • Any container listed with allowPrivilegeEscalation: true is a potential problem and requires human review to decide if it is strictly necessary or should be disallowed by namespace policy (e.g., by enforcing pod-security.kubernetes.io/enforce=restricted).
Automation
#!/usr/bin/env bash
# Report namespaces that allow pods with allowPrivilegeEscalation=true
# Requires: kubectl, jq

set -euo pipefail

echo "== Pod Security admission labels per namespace =="
kubectl get ns \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{"enforce="}{.metadata.labels.pod-security\.kubernetes\.io/enforce}{"\t"}{"warn="}{.metadata.labels.pod-security\.kubernetes\.io/warn}{"\n"}{end}' \
  | sort

echo
echo "== Namespaces without enforce=restricted label (user workloads may be less restricted) =="
kubectl get ns \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{"enforce="}{.metadata.labels.pod-security\.kubernetes\.io/enforce}{"\n"}{end}' \
  | awk '$2 != "enforce=restricted"' \
  | sort

echo
echo "== Workload pods that explicitly set allowPrivilegeEscalation=true =="
echo "NOTE: This inspects current pods; review by namespace and workload owner."
kubectl get pods --all-namespaces -o json | jq -r '
  .items[]
  | {
      ns: .metadata.namespace,
      pod: .metadata.name,
      owner: (
        .metadata.ownerReferences[0].kind + "/" +
        .metadata.ownerReferences[0].name
      ) // "POD (no controller)",
      containers: (
        (.spec.containers // []) + (.spec.initContainers // [])
      )
    }
  | .containers[]
  | select(.securityContext.allowPrivilegeEscalation == true)
  | [.ns, .pod, .owner, .name, (.securityContext.allowPrivilegeEscalation|tostring)]
  | @tsv
' 2>/dev/null \
| awk 'BEGIN{OFS="\t"; print "NAMESPACE","POD","OWNER","CONTAINER","allowPrivilegeEscalation"}1' \
| column -t

echo
echo "== Summary =="
echo "1) Namespaces where enforce!=restricted (above) are candidates to tighten with:"
echo "   kubectl label --overwrite ns <NAMESPACE> pod-security.kubernetes.io/enforce=restricted"
echo
echo "2) Any rows in the allowPrivilegeEscalation report above indicate a problem for this control:"
echo "   - Each line shows a container that explicitly sets allowPrivilegeEscalation=true."
echo "   - Review by namespace and OWNER, then update workload manifests to drop or set it to false."

How to interpret the output (what indicates a problem)

  • In “Namespaces without enforce=restricted label”:

    • Any user-workload namespace listed here is a potential issue; it is not enforcing the restricted Pod Security level that blocks allowPrivilegeEscalation=true.
    • System namespaces (e.g. kube-system, gatekeeper-system, CNI/CSI namespaces) may legitimately appear and should be reviewed, not blindly changed.

  • In “Workload pods that explicitly set allowPrivilegeEscalation=true”:

    • Every line is a concrete violation of this control.
    • Each row identifies: NAMESPACE, POD, owning controller (OWNER), and CONTAINER name.
    • These workloads should be reviewed and, where appropriate, updated so containers do not set allowPrivilegeEscalation=true, then guarded via namespace labels as per the benchmark remediation.

Additional Reading:​