> ## 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 Access Create Pods

### More Info:

The ability to create pods in a namespace can provide a number of opportunities for privilege escalation, such as assigning privileged service accounts to these pods or mounting hostPaths with access to sensitive data (unless Pod Security Policies are implemented to restrict this access)

### Risk Level

Low

### 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

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

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **Identify who can create Pods in each namespace**\
           Run on any machine with `kubectl` access:
           ```bash theme={null}
           kubectl auth can-i create pods --all-namespaces --as system:serviceaccount:kube-system:default
           ```
           To list all subjects with `create` on `pods` (Role/RoleBinding + ClusterRole/ClusterRoleBinding):
           ```bash theme={null}
           kubectl get role,clusterrole -A -o yaml | grep -nA5 "resources:.*pods" | grep -B3 "verbs:.*create"
           kubectl get rolebinding,clusterrolebinding -A -o yaml > /tmp/rb-crb.yaml
           ```
           Inspect `/tmp/rb-crb.yaml` to map roles with `create` on `pods` to users/groups/serviceaccounts.

        2. **Review necessity of Pod creation for each subject**\
           For each Role/ClusterRole that allows `create` on `pods`, decide if it is truly needed:
           ```bash theme={null}
           # Example: inspect one role in detail
           kubectl get role -n <namespace> <role-name> -o yaml
           kubectl get clusterrole <clusterrole-name> -o yaml
           ```
           Cross-check with application/CI/CD design docs and workload requirements for that namespace; flag any human users or broad groups (e.g. `system:authenticated`) that don’t require direct pod creation.

        3. **Scope down or remove excessive Pod creation permissions**\
           For each unnecessary permission, edit the binding or role:
           ```bash theme={null}
           # Edit Role to remove 'create' on pods (least privilege)
           kubectl edit role -n <namespace> <role-name>

           # Or edit ClusterRole
           kubectl edit clusterrole <clusterrole-name>

           # Or remove an overly broad binding entirely
           kubectl delete rolebinding -n <namespace> <binding-name>
           kubectl delete clusterrolebinding <binding-name>
           ```
           In the editor, remove `create` from `verbs` under the rule with `resources: ["pods"]`, or delete the whole rule if Pod access is not required.

        4. **Prefer higher-level or constrained permissions where needed**\
           For subjects that legitimately need to run workloads, replace direct Pod creation with safer alternatives where possible:
           * Grant permissions on `deployments`, `statefulsets`, `jobs`, etc. instead of `pods`.
           * If Pod creation is required, constrain it using:
             ```bash theme={null}
             # Example: ensure a restricted Pod Security configuration / namespace label is in place
             kubectl label namespace <namespace> pod-security.kubernetes.io/enforce=restricted --overwrite=true
             ```
           Document each case where `create pods` remains necessary and why.

        5. **Re‑verify effective permissions after changes**\
           Re-run access checks to confirm that unnecessary Pod creation rights are removed:
           ```bash theme={null}
           kubectl get role,clusterrole -A -o yaml | grep -nA5 "resources:.*pods" | grep -B3 "verbs:.*create"
           ```
           For specific high‑risk identities (e.g. human admins, CI service accounts), validate explicitly:
           ```bash theme={null}
           kubectl auth can-i create pods -n <namespace> --as <user-or-sa>
           ```

        6. **Optionally test by simulating Pod creation attempts**\
           For a sampled set of users/service accounts:
           ```bash theme={null}
           kubectl --as <user-or-sa> -n <namespace> run test-pod --image=busybox --restart=Never -- sleep 60
           ```
           Expect failure (`no`, or “forbidden”) for identities that should not be able to create Pods, and success only for those explicitly approved. Clean up any test Pods you created:
           ```bash theme={null}
           kubectl delete pod test-pod -n <namespace> --ignore-not-found
           ```
      </Accordion>

      <Accordion title="Using kubectl">
        ### Using kubectl

        Run these commands from any machine with `kubectl` access.

        #### 1. Find who can create pods cluster-wide

        ```bash theme={null}
        kubectl get clusterrole -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .rules[*]}{"  "}{.verbs}{" -> "}{.resources}{"\n"}{end}{"\n"}{end}' | grep -B1 "pods" | grep -B1 "create"
        ```

        Problem indication:

        * Any `ClusterRole` where `verbs` includes `create` and `resources` includes `pods` means *cluster-wide* permission to create pods.
        * Especially review broad roles like `cluster-admin`, `edit`, or custom roles used by many subjects.

        List which subjects are bound to those `ClusterRole`s:

        ```bash theme={null}
        kubectl get clusterrolebindings -o wide
        ```

        Problem indication:

        * `ClusterRoleBinding` objects that bind the above roles to `system:authenticated`, large groups (e.g. `developers`), or service accounts not meant to manage workloads indicate over-granting.

        To see details for a specific binding:

        ```bash theme={null}
        kubectl get clusterrolebinding <binding-name> -o yaml
        ```

        #### 2. Find who can create pods in each namespace

        List all `Role`s that allow pod creation:

        ```bash theme={null}
        for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
          echo "=== Namespace: $ns ==="
          kubectl get role -n "$ns" -o json | \
            jq -r '.items[] | select(.rules[]? | (.resources[]? == "pods") and (.verbs[]? == "create")) | .metadata.name'
        done
        ```

        Problem indication:

        * Any `Role` in sensitive namespaces (e.g. `kube-system`, `security`, `prod`) with `resources: ["pods"]` and `verbs` including `create` needs careful justification.

        Show who is bound to those `Role`s:

        ```bash theme={null}
        for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
          echo "=== Namespace: $ns ==="
          kubectl get rolebinding -n "$ns" -o yaml | \
            grep -E "^(kind: RoleBinding|  name: |  kind: (User|Group|ServiceAccount)|  name: .*|  namespace: )"
        done
        ```

        For a specific namespace with many workloads (e.g. `prod`):

        ```bash theme={null}
        kubectl get role -n prod -o yaml | grep -n "pods" -n
        kubectl get rolebinding -n prod -o yaml
        ```

        Problem indication:

        * `RoleBinding`s that attach pod-creating `Role`s to broad groups or many service accounts (e.g. generic CI accounts, default service accounts) signal overly permissive pod-creation rights.

        #### 3. Use `kubectl auth can-i` to spot effective access

        Test specific identities (substitute actual user or service account):

        ```bash theme={null}
        # As current kubectl identity
        kubectl auth can-i create pods --all-namespaces

        # As a specific user
        kubectl auth can-i create pods --all-namespaces --as=user@example.com

        # As a service account in a namespace
        kubectl auth can-i create pods -n prod --as=system:serviceaccount:prod:ci-bot
        ```

        Problem indication:

        * `yes` for `--all-namespaces` or in sensitive namespaces for identities that should not manage workloads indicates excessive access to create pods.

        These commands show where pod creation is currently allowed; a human must decide which roles/bindings are justified and which should be restricted or removed.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        # Report who can create pods across the whole cluster
        # Runs on: any machine with kubectl access and appropriate RBAC

        set -euo pipefail

        echo "=== Cluster-wide (non-namespaced) permissions to create pods ==="
        kubectl auth can-i create pods --all-namespaces=false --as=system:anonymous 2>/dev/null || true
        echo "Note: Above is a simple anonymous check; detailed RBAC is below."

        echo
        echo "=== Detailed RBAC: Roles/ClusterRoles that allow create on pods ==="

        # 1) ClusterRoles with create on pods
        echo
        echo "---- ClusterRoles with 'create' on pods ----"
        kubectl get clusterroles -o json \
          | jq -r '
            .items[]
            | {name: .metadata.name, rules: .rules}
            | select(.rules != null)
            | select(
                .rules[]
                | select(
                    ((.verbs // []) | index("create"))
                    and
                    (
                      ((.resources // []) | index("pods"))
                      or
                      ((.resources // []) | index("*"))
                    )
                  )
              )
            | .name' \
          | sort -u

        # 2) Namespaced Roles with create on pods, grouped by namespace
        echo
        echo "---- Roles (namespaced) with 'create' on pods ----"
        kubectl get roles --all-namespaces -o json \
          | jq -r '
            .items[]
            | {ns: .metadata.namespace, name: .metadata.name, rules: .rules}
            | select(.rules != null)
            | select(
                .rules[]
                | select(
                    ((.verbs // []) | index("create"))
                    and
                    (
                      ((.resources // []) | index("pods"))
                      or
                      ((.resources // []) | index("*"))
                    )
                  )
              )
            | "\(.ns) \(.name)"' \
          | sort -u

        # 3) Bindings: who gets the above roles/clusterroles
        echo
        echo "=== ClusterRoleBindings (cluster-wide subjects that may create pods) ==="
        kubectl get clusterrolebindings -o json \
          | jq -r '
            .items[]
            | {name: .metadata.name, roleRef: .roleRef, subjects: (.subjects // [])}
            | select(.roleRef.kind == "ClusterRole")
            | select(.roleRef.name != "")
            | "\(.name)\trole=\(.roleRef.name)\tsubjects=" +
              (if (.subjects | length) == 0 then "NONE"
               else (.subjects | map("\(.kind):\(.namespace // "-")/\(.name)") | join(","))
               end)
          ' \
          | sort

        echo
        echo "=== RoleBindings (namespaced subjects that may create pods) ==="
        kubectl get rolebindings --all-namespaces -o json \
          | jq -r '
            .items[]
            | {ns: .metadata.namespace, name: .metadata.name, roleRef: .roleRef, subjects: (.subjects // [])}
            | "\(.ns)\t\(.name)\troleKind=\(.roleRef.kind)\troleName=\(.roleRef.name)\tsubjects=" +
              (if (.subjects | length) == 0 then "NONE"
               else (.subjects | map("\(.kind):\(.namespace // "-")/\(.name)") | join(","))
               end)
          ' \
          | sort

        echo
        echo "=== Summary hints ==="
        cat <<'EOF'
        Review focus:

        1) ClusterRoles shown above, especially:
           - Roles with resources: ["*"] or including "pods"
           - Verbs including "create"
           - Roles bound to:
             * system:authenticated (all logged-in users)
             * system:serviceaccounts or system:serviceaccounts:<ns>
             * broad groups (e.g. devs, ci, platform) that do not need pod-creation rights

        2) Namespaces:
           - Pay attention to production or sensitive namespaces where few identities
             should be able to create pods.

        Indicators of a potential problem:

        - Any ClusterRole with create on pods bound (via ClusterRoleBinding) to:
          * system:authenticated
          * system:serviceaccounts
          * large user groups not tied to a specific app/team
        - RoleBindings in sensitive namespaces granting pod creation to:
          * Generic groups (e.g. "developers") instead of specific service accounts
          * Default service accounts or broad serviceaccount groups
        - Roles that include:
          * resources: ["*"] and verbs: ["*"] or including "create"
          * resources including "pods" with verbs including "create"
            for subjects that do not require full pod lifecycle control.

        Use this report to decide where to tighten RBAC by:
        - Editing or replacing Roles/ClusterRoles to remove "create" on "pods"
        - Narrowing or removing RoleBindings/ClusterRoleBindings that grant such roles
          in namespaces or to subjects that do not strictly require it.
        EOF
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>