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

### More Info:

The ability to create pods can be abused to run privileged workloads or bypass admission controls. Restrict create access to pod objects to only the subjects that require it.

### 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. **List all roles/clusterroles that can create pods**
           * Run on: any machine with kubectl access
           * Command:
             ```bash theme={null}
             kubectl get clusterrole,role -A -o json \
               | jq -r '.items[]
                 | select(.rules[]? 
                   | any(.apiGroups[]? == "" and .resources[]? == "pods" and (.verbs[]? == "create" or .verbs[]? == "*")))
                 | (.kind + "/" + .metadata.name + " (ns: " + (.metadata.namespace // "-cluster-") + ")")'
             ```

        2. **Identify which subjects are bound to those roles**
           * Run on: any machine with kubectl access
           * For each name from step 1, get the bindings:
             ```bash theme={null}
             # Example for a ClusterRole
             kubectl get clusterrolebindings.rbac.authorization.k8s.io -o yaml \
               | yq '.items[] | select(.roleRef.kind == "ClusterRole" and .roleRef.name == "<CLUSTERROLE_NAME>")'

             # Example for a namespaced Role
             kubectl get rolebindings.rbac.authorization.k8s.io -A -o yaml \
               | yq '.items[] | select(.roleRef.kind == "Role" and .roleRef.name == "<ROLE_NAME>")'
             ```
           * Record which users, groups, and service accounts have pod create access, and in which namespaces.

        3. **Decide which subjects truly need pod creation capability**
           * For each subject from step 2, review:
             * What application or team it belongs to.
             * Whether it must create pods (e.g., controllers, CI/CD, autoscalers) or only needs to manage higher‑level objects (Deployments, Jobs, etc.).
           * Document for each subject: “needs pod create” or “does not need pod create”.

        4. **Remove unnecessary pod create verbs from roles**
           * Run on: any machine with kubectl access
           * For each Role/ClusterRole where some or all subjects do not need pod creation:\
             a) If *no* bound subjects need pod creation, remove the `create` (and `*` if present) verb for pods from the rule:
             ```bash theme={null}
             kubectl edit clusterrole <CLUSTERROLE_NAME>
             # or
             kubectl edit role -n <NAMESPACE> <ROLE_NAME>
             ```
             * In the editor, locate rules with:
               ```yaml theme={null}
               apiGroups: [""]
               resources: ["pods"]
               verbs: ["create", ...]  # or ["*"]
               ```
               and remove `create` (or replace `*` with the minimal required verbs excluding `create`).\
               b) If some subjects still require pod creation but others do not, create a new limited role and rebind:
             ```bash theme={null}
             kubectl create role <NEW_ROLE_NAME> \
               --verb=get,list,watch,update,patch,delete \
               --resource=pods \
               -n <NAMESPACE>

             kubectl create rolebinding <NEW_BINDING_NAME> \
               --role=<NEW_ROLE_NAME> \
               --serviceaccount=<NAMESPACE>:<SERVICEACCOUNT_NAME> \
               -n <NAMESPACE>
             ```
             * Then remove the unnecessary subjects from the original binding via:
               ```bash theme={null}
               kubectl edit rolebinding -n <NAMESPACE> <OLD_BINDING_NAME>
               ```

        5. **Revalidate effective permissions after changes**
           * Run on: any machine with kubectl access
           * For each key subject, confirm whether it can still create pods:
             ```bash theme={null}
             # For a user
             kubectl auth can-i create pods --as=<USER_NAME> -n <NAMESPACE>

             # For a service account
             kubectl auth can-i create pods \
               --as=system:serviceaccount:<NAMESPACE>:<SA_NAME> \
               -n <NAMESPACE>
             ```
           * Expect `no` for all subjects that do not require pod creation, and `yes` only for explicitly approved subjects.

        6. **Periodic review and evidence collection**
           * Run on: any machine with kubectl access
           * Capture current state for audit purposes and future reviews:
             ```bash theme={null}
             kubectl get clusterrole,role -A -o yaml > pod-create-roles-snapshot.yaml
             kubectl get clusterrolebinding,rolebinding -A -o yaml > pod-create-bindings-snapshot.yaml
             ```
           * Schedule periodic re‑runs of steps 1–5 or integrate them into CI/CD or policy-as-code to ensure ongoing minimization of pod create access.
      </Accordion>

      <Accordion title="Using kubectl">
        ```bash theme={null}
        # 1) List all ClusterRoles that can create pods
        # Run on: any machine with kubectl access

        kubectl get clusterroles -o json | \
          jq -r '
            .items[]
            | select(
                .rules[]
                | select(
                    (.verbs | index("create"))
                    and
                    (.resources | index("pods"))
                  )
              )
            | .metadata.name
          ' | sort -u
        ```

        Problem indication: Any ClusterRole listed here grants `create` on `pods`. Every such role must be reviewed to confirm it’s truly needed.

        ***

        ```bash theme={null}
        # 2) Show full definitions of those ClusterRoles for review
        # Replace <ROLE_NAME> with each name from the previous command

        kubectl get clusterrole <ROLE_NAME> -o yaml
        ```

        What to look for in the output (problem indications):

        * `resources: ["pods"]` or `resources: ["*"]` combined with `verbs` including `"create"` or `"*"`.
        * Broad use of `apiGroups: ["*"]` or `resources: ["*"]` where pod creation is not clearly necessary.
        * ClusterRoles with pod-create rights that are clearly generic (e.g. `edit`, `admin`, custom “developer” roles) rather than narrowly scoped operational roles.

        ***

        ```bash theme={null}
        # 3) Find which subjects are bound to those ClusterRoles
        # Run for each ClusterRole identified

        kubectl get clusterrolebindings -o json | \
          jq -r '
            .items[]
            | select(.roleRef.kind=="ClusterRole" and .roleRef.name=="<ROLE_NAME>")
            | "ClusterRoleBinding: \(.metadata.name)\n  Subjects: \(.subjects // [])"
          '
        ```

        Problem indication: Highly privileged or generic subjects (e.g. broad groups like `system:authenticated`, `developers`, or many service accounts across namespaces) bound to ClusterRoles that can create pods.

        ***

        ```bash theme={null}
        # 4) Find RoleBindings in namespaces that reference ClusterRoles granting pod create
        # Replace <ROLE_NAME> with each name from step 1

        kubectl get rolebindings --all-namespaces -o json | \
          jq -r '
            .items[]
            | select(.roleRef.kind=="ClusterRole" and .roleRef.name=="<ROLE_NAME>")
            | "Namespace: \(.metadata.namespace)\n  RoleBinding: \(.metadata.name)\n  Subjects: \(.subjects // [])"
          '
        ```

        Problem indication: Namespaced RoleBindings exposing pod-create rights via ClusterRoles to many users or generic groups across multiple namespaces.

        ***

        ```bash theme={null}
        # 5) Check namespace-scoped Roles that can create pods
        kubectl get roles --all-namespaces -o json | \
          jq -r '
            .items[]
            | select(
                .rules[]
                | select(
                    (.verbs | index("create"))
                    and
                    (.resources | index("pods"))
                  )
              )
            | "Namespace: \(.metadata.namespace) Role: \(.metadata.name)"
          ' | sort
        ```

        Problem indication: Roles in many namespaces granting pod `create` to non-operational subjects or generic “developer”/“default” subjects, indicating pod creation is widely available.

        ***

        Interpretation guidance (manual decision):

        * Acceptable: tightly scoped Roles/ClusterRoles used by:
          * CI/CD or controllers that must create pods.
          * Operational teams in specific namespaces where pod creation is required.
        * Concerning:
          * Global or semi-global roles bound to large groups (`system:authenticated`, all developers).
          * Roles where `resources: ["*"]` and `verbs: ["*"]` or `"create"` are present without a clear operational justification.
          * Service accounts in many namespaces that can create pods despite not being controllers.
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        #
        # Report subjects that can create pods, cluster-wide and per-namespace.
        # Run from: any machine with kubectl access and correct context.
        # Requirements: bash, kubectl, jq

        set -euo pipefail

        echo "=== Cluster-wide (ClusterRole/ClusterRoleBinding) pod CREATE permissions ==="
        echo

        # 1) All ClusterRoles that grant create on pods
        kubectl get clusterroles -o json \
          | jq -r '
            .items[]
            | {name: .metadata.name, rules: .rules}
            | select(
                .rules != null
                and any(.rules[]?;
                  (.apiGroups // []) | index("") != null
                  and (.resources // []) | index("pods") != null
                  and (.verbs // []) | index("create") != null
                )
              )
            | .name
          ' | sort -u | while read -r cr; do
              echo "ClusterRole: ${cr}"
              # Show exact rules that allow pod create
              kubectl get clusterrole "${cr}" -o json \
                | jq -r '
                  .rules[]
                  | select(
                      (.apiGroups // []) | index("") != null
                      and (.resources // []) | index("pods") != null
                      and (.verbs // []) | index("create") != null
                    )
                ' | jq .
              echo

              echo "  Bound via ClusterRoleBindings to:"
              kubectl get clusterrolebindings -o json \
                | jq -r --arg CR "${cr}" '
                    .items[]
                    | select(.roleRef.kind=="ClusterRole" and .roleRef.name==$CR)
                    | .metadata.name as $crb
                    | .subjects[]? 
                    | "\($crb)\t\(.kind)\t\(.namespace // "-")\t\(.name)"
                ' 2>/dev/null | sort -u || true
              echo
              echo "-------------------------------------------------------------------"
              echo
            done

        echo
        echo "=== Namespace-scoped (Role/RoleBinding) pod CREATE permissions ==="
        echo

        # 2) All Roles that grant create on pods, per-namespace
        kubectl get roles --all-namespaces -o json \
          | jq -r '
            .items[]
            | {ns: .metadata.namespace, name: .metadata.name, rules: .rules}
            | select(
                .rules != null
                and any(.rules[]?;
                  (.apiGroups // []) | index("") != null
                  and (.resources // []) | index("pods") != null
                  and (.verbs // []) | index("create") != null
                )
              )
            | "\(.ns)\t\(.name)"
          ' | sort -u | while IFS=$'\t' read -r ns role; do
              echo "Role: ${role} (namespace: ${ns})"
              # Show exact rules that allow pod create
              kubectl get role "${role}" -n "${ns}" -o json \
                | jq -r '
                  .rules[]
                  | select(
                      (.apiGroups // []) | index("") != null
                      and (.resources // []) | index("pods") != null
                      and (.verbs // []) | index("create") != null
                    )
                ' | jq .
              echo

              echo "  Bound via RoleBindings to:"
              kubectl get rolebindings -n "${ns}" -o json \
                | jq -r --arg ROLE "${role}" '
                    .items[]
                    | select(.roleRef.kind=="Role" and .roleRef.name==$ROLE)
                    | .metadata.name as $rb
                    | .subjects[]?
                    | "\($rb)\t\(.kind)\t\(.namespace // "-")\t\(.name)"
                ' 2>/dev/null | sort -u || true
              echo
              echo "-------------------------------------------------------------------"
              echo
            done

        cat <<'EOF'

        How to interpret this report:

        - Every listed ClusterRole or Role has rules allowing "create" on core "pods".
        - For each such role, the script shows:
          - The exact rule blocks that grant create on pods.
          - Which users/groups/serviceaccounts (subjects) receive that permission via bindings.

        Potential problems to investigate:

        - Any subject that does not strictly need to create pods in production or sensitive namespaces.
        - Broad subjects such as:
          - "system:authenticated", "system:unauthenticated", or large identity groups.
          - Wildcard subjects (e.g., many service accounts bound via a shared group).
        - Bindings in critical namespaces (kube-system, kube-public, security-sensitive app namespaces)
          where pod creation should be tightly controlled.

        Use this report to decide, case by case, which roles/bindings should be narrowed or removed.
        There is no safe one-size-fits-all automated removal for this permission; changes must follow
        your change-management and application requirements review.

        EOF
        ```
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>