> ## 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 Admission Of Containers With allowPrivilegeEscalation

### More Info:

Containers with allowPrivilegeEscalation set to true can gain more privileges than their parent process. Enforce policies that restrict admission of such containers.

### Risk Level

High

### Address

Security

### Compliance Standards

* CIS OKE

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Identify current use of `allowPrivilegeEscalation` across workloads**
           * Run on: any machine with kubectl access
           * Command:
             ```bash theme={null}
             kubectl get pods --all-namespaces -o json \
               | jq -r '
                 .items[]
                 | {ns:.metadata.namespace, pod:.metadata.name, ctrs:(.spec.containers + (.spec.initContainers // []))}
                 | .ctrs[]
                 | select(.securityContext.allowPrivilegeEscalation == true)
                 | "\(.ns) \(.pod) \(.name) allowPrivilegeEscalation=true"
               '
             ```
           * Save the output and review which namespaces/pods/containers currently rely on `allowPrivilegeEscalation=true`.

        2. **Assess necessity and impact per workload**
           * For each listed container:
             * Check its manifest:
               ```bash theme={null}
               kubectl get pod <pod-name> -n <namespace> -o yaml
               ```
             * Review with the workload owner whether privilege escalation is truly required (e.g., needs to setuid, load kernel modules, manipulate other users’ processes).
             * Classify each as: “must have”, “can be removed now”, or “needs migration work”.

        3. **Design namespace-level policy using Pod Security Admission or a policy engine**
           * If using Pod Security Admission (recommended for OKE where available):
             * Decide which namespaces need to run privileged or legacy workloads and which should be restricted.
             * Example: mark “restricted” namespaces to block privilege escalation:
               ```bash theme={null}
               kubectl label namespace <namespace> \
                 pod-security.kubernetes.io/enforce=restricted \
                 pod-security.kubernetes.io/enforce-version=latest \
                 --overwrite
               ```
           * If using a policy engine (e.g., Gatekeeper/Kyverno), plan a policy that denies pods where any container has `securityContext.allowPrivilegeEscalation=true`, with explicit exceptions for approved namespaces or workloads.

        4. **Implement or tighten the policy and test against current workloads**
           * Apply or update the chosen policy configuration (namespace labels or policy CRDs) according to your platform’s standard process.
           * Before enforcing, use “audit” or “dry-run” modes where supported to detect which existing pods/Deployments would be blocked:
             * For Pod Security Admission, inspect namespace warnings when applying manifests.
             * For Gatekeeper/Kyverno, check policy “audit” reports or `kubectl describe` on the policy object to see violations.

        5. **Remediate or exempt necessary workloads**
           * For each container classified as “can be removed now”:
             * Update its Deployment/StatefulSet/Pod manifest to explicitly set:
               ```yaml theme={null}
               securityContext:
                 allowPrivilegeEscalation: false
               ```
             * Apply the change:
               ```bash theme={null}
               kubectl apply -f <updated-manifest>.yaml
               ```
           * For each “must have” or “needs migration work” workload:
             * Either place it in a dedicated namespace with a less-restrictive policy and clear justification, or define a narrowly scoped exception in your policy engine.
             * Document the justification and planned timeline for reduction where possible.

        6. **Verify policy effectiveness and ongoing compliance**
           * Re-run the evidence command:
             ```bash theme={null}
             kubectl get pods --all-namespaces -o json \
               | jq -r '
                 .items[]
                 | {ns:.metadata.namespace, pod:.metadata.name, ctrs:(.spec.containers + (.spec.initContainers // []))}
                 | .ctrs[]
                 | select(.securityContext.allowPrivilegeEscalation == true)
                 | "\(.ns) \(.pod) \(.name) allowPrivilegeEscalation=true"
               '
             ```
           * Confirm that:
             * “Restricted” namespaces no longer admit new pods with `allowPrivilegeEscalation=true`.
             * Any remaining instances are explicitly approved exceptions with documented risk and controls.
      </Accordion>

      <Accordion title="Using kubectl">
        ```bash theme={null}
        # 1) List all namespaces that may need policies
        # Run on: any machine with kubectl access
        kubectl get ns
        ```

        Review which namespaces contain user workloads (exclude system namespaces such as `kube-system`, `kube-public`, `kube-node-lease`, and provider-specific system namespaces). For each user namespace, inspect current pods:

        ```bash theme={null}
        # 2) List all pods in a namespace, including their security context
        # Replace <namespace> with the namespace to review
        kubectl get pods -n <namespace> -o yaml | grep -nE 'name:|securityContext:|allowPrivilegeEscalation'
        ```

        Output is a YAML stream; lines like:

        ```yaml theme={null}
        securityContext:
          allowPrivilegeEscalation: true
        ```

        or container-level:

        ```yaml theme={null}
        containers:
        - name: app
          securityContext:
            allowPrivilegeEscalation: true
        ```

        indicate containers that currently allow privilege escalation and therefore should be reviewed.

        To see the full definition for a specific pod with a suspect setting:

        ```bash theme={null}
        # 3) Describe a specific pod
        kubectl get pod <pod-name> -n <namespace> -o yaml
        ```

        Look for `securityContext` at both pod and container level; any explicit `allowPrivilegeEscalation: true` is a potential problem.

        Next, inspect whether the namespace has any admission policies (Pod Security Standards, PodSecurityPolicy if legacy, or custom policies) that would restrict such pods:

        ```bash theme={null}
        # 4) Check Pod Security admission labels on the namespace (if using built-in Pod Security)
        kubectl get ns <namespace> -o yaml | grep -n 'pod-security.kubernetes.io'
        ```

        If there are no `pod-security.kubernetes.io/*` labels, or they are set to a privileged mode (e.g. `privileged` or a custom relaxed configuration elsewhere), the namespace likely does not restrict `allowPrivilegeEscalation: true`.

        If you are using admission webhooks (e.g., Gatekeeper, Kyverno), list related resources for review:

        ```bash theme={null}
        # 5) (Gatekeeper example) List constraints that might govern allowPrivilegeEscalation
        kubectl get constrainttemplates,gkconstraints,validatingwebhookconfigurations -A
        ```

        Absence of any constraints or webhook configurations that mention `allowPrivilegeEscalation` or container privilege in their names/annotations suggests the cluster may not be enforcing restrictions.

        Verification after any policy changes (manual, outside the scope of these commands):

        ```bash theme={null}
        # 6) Re-scan pods in the namespace to confirm where allowPrivilegeEscalation is still in use
        kubectl get pods -n <namespace> -o yaml | grep -n 'allowPrivilegeEscalation'
        ```

        Any remaining `allowPrivilegeEscalation: true` entries highlight pods that are either exempted by policy or running in namespaces without restrictive policies and need human review against your risk tolerance.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        # Report pods whose containers can escalate privileges (allowPrivilegeEscalation=true or unset)

        set -euo pipefail

        # Requires: kubectl, jq
        # Runs on: any machine with kubectl access and cluster-wide read permissions

        echo "=== Scanning all namespaces for pods with allowPrivilegeEscalation risk ===" >&2

        # 1) List all pods with full spec as JSON
        pods_json="$(kubectl get pods --all-namespaces -o json)"

        # 2) For each pod, print containers where allowPrivilegeEscalation is true or not set
        echo
        echo "Namespace,Pod,Container,Type,allowPrivilegeEscalation,Source"
        echo "---------,---,---------,----,------------------------,------"

        echo "${pods_json}" | jq -r '
          .items[]
          | . as $pod
          | (
              # normal containers
              ($pod.spec.containers[]? | {type:"container", name:.name, secc: .securityContext})
            ),
            (
              # initContainers
              ($pod.spec.initContainers[]? | {type:"initContainer", name:.name, secc: .securityContext})
            ),
            (
              # ephemeralContainers
              ($pod.spec.ephemeralContainers[]? | {type:"ephemeralContainer", name:.name, secc: .securityContext})
            )
          | . as $c
          | ($pod.metadata.namespace // "default") as $ns
          | ($pod.metadata.name) as $podname
          | ($c.name) as $cname
          | ($c.type) as $ctype
          | ($c.secc // {}) as $secc
          |
          # Determine effective allowPrivilegeEscalation for the container:
          # 1. Container.securityContext.allowPrivilegeEscalation if set
          # 2. Else Pod.spec.securityContext.allowPrivilegeEscalation if set
          # 3. Else "unset" (treated as risky)
          (
            if ($secc.allowPrivilegeEscalation != null) then
              {ape: $secc.allowPrivilegeEscalation, source: "container.securityContext"}
            else
              (
                if ($pod.spec.securityContext.allowPrivilegeEscalation != null) then
                  {ape: $pod.spec.securityContext.allowPrivilegeEscalation, source: "pod.securityContext"}
                else
                  {ape: "unset", source: "not-specified"}
                end
              )
            end
          ) as $eff
          |
          # Only print rows that are risky: allowPrivilegeEscalation=true or unset
          select($eff.ape == true or $eff.ape == "unset")
          |
          [
            $ns,
            $podname,
            $cname,
            $ctype,
            ($eff.ape|tostring),
            $eff.source
          ]
          | @csv
        '

        cat <<'EOF'

        Interpretation:

        - Every printed line represents a container that is NOT compliant with the intent
          of "Minimize admission of containers with allowPrivilegeEscalation":

          Columns:
            Namespace                 Namespace of the pod
            Pod                       Pod name
            Container                 Container name
            Type                      container | initContainer | ephemeralContainer
            allowPrivilegeEscalation  "true" or "unset"
            Source                    Where the value comes from:
                                      - container.securityContext
                                      - pod.securityContext
                                      - not-specified (no explicit setting)

        - Problematic output:
          - allowPrivilegeEscalation == "true":
              The container explicitly allows privilege escalation and should be reviewed
              and restricted by admission policies if not strictly required.
          - allowPrivilegeEscalation == "unset":
              No explicit setting; effective behavior depends on cluster defaults.
              Treat these as needing review and policy coverage.

        - If the script prints NO data rows (only the header and this explanation),
          then all containers explicitly set allowPrivilegeEscalation=false, which is
          the desired state from a workload perspective. You still need to ensure
          admission policies are in place per namespace as required by the benchmark.
        EOF
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>