Minimize Access To Create Pods

Manual Steps

List all roles/clusterroles that can create pods

Run on: any machine with kubectl access

Command:

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-") + ")")'

Identify which subjects are bound to those roles

Run on: any machine with kubectl access

For each name from step 1, get the bindings:

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

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”.

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:

kubectl edit clusterrole <CLUSTERROLE_NAME>
# or
kubectl edit role -n <NAMESPACE> <ROLE_NAME>

In the editor, locate rules with:
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:

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:
kubectl edit rolebinding -n <NAMESPACE> <OLD_BINDING_NAME>

Revalidate effective permissions after changes
- Run on: any machine with kubectl access
- For each key subject, confirm whether it can still create pods:
  # 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.
Periodic review and evidence collection
- Run on: any machine with kubectl access
- Capture current state for audit purposes and future reviews:
  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.

Using kubectl

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

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

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

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

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

Automation

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

OCI Misconfigurations

Minimize Access To Create Pods

More Info:

Risk Level

Address

Compliance Standards

Triage and Remediation

Remediation

​More Info:

​Risk Level

​Address

​Compliance Standards

​Triage and Remediation

​Remediation