Skip to main content

More Info:

The ability to create pods can be abused to run privileged workloads or escalate privileges. This permission should be restricted to only required service accounts.

Risk Level

High

Address

Security

Compliance Standards

  • CIS AKS

Triage and Remediation

Remediation

Manual Steps

  1. List all Roles/ClusterRoles that can create pods
    Run on any machine with kubectl access:
  2. Review each identified Role/ClusterRole’s scope and necessity
    For each name from step 1, inspect full rules and annotations:
    Decide whether the subjects using this role truly need to create pods, or if they could use higher‑level abstractions (Deployments/Jobs) or narrower permissions instead.
  3. Identify who is bound to these Roles/ClusterRoles
    For each Role/ClusterRole discovered, list RoleBindings/ClusterRoleBindings:
    Then inspect each binding to see which users/groups/serviceaccounts are granted pod creation:
  4. Decide and implement least-privilege changes
    For each combination of Role/ClusterRole and binding:
    • If pod creation is not required: remove create on pods from the role rules.
      In the editor, delete create from the verbs list for the pods resource, or remove the rule stanza entirely if no longer needed.
    • If some but not all subjects need this permission: create a new, narrowly scoped Role/ClusterRole just for those subjects, and update bindings so only those specific serviceaccounts/users/groups are bound to it.
  5. Tighten or remove unnecessary bindings
    Where overly broad subjects are found (e.g., groups like system:authenticated or wildcard-like coverage):
    • Replace broad bindings with bindings to specific service accounts or users that actually require pod creation.
    • Remove RoleBindings/ClusterRoleBindings that are no longer needed:
  6. Verify that pod creation access is minimized
    Re-run the evidence commands to confirm only the intended Roles/ClusterRoles retain pod creation:
    Confirm that each remaining role with create on pods is intentionally required and bound only to the minimal set of subjects.

Using kubectl

Run the following from any machine with kubectl access.
  1. List all Roles/ClusterRoles that can create pods
Problem indication: Any role/clusterrole appears here that is not clearly intended to create pods (for example, broad “admin”-style roles granted to many subjects, or generic application roles).
  1. Inspect detailed rules for each identified role
For ClusterRoles (replace <clusterrole-name> with each name from step 1):
For Roles (replace <namespace> and <role-name>):
In the rules section, look for:
  • resources: ["pods"] (or including pods)
  • verbs: ["create"] (or including create or *)
Problem indication:
Rules that allow create on pods (directly, via * verbs, or via * resources) tied to functions that do not strictly require pod creation, or overly broad rules (e.g., verbs: ["*"] or resources: ["*"]).
  1. See who is bound to these Roles/ClusterRoles
For each ClusterRole:
For each namespaced Role:
Problem indication:
Bindings that grant these permissions to:
  • system:authenticated, system:unauthenticated, or other large groups.
  • Generic groups like “developers” or many service accounts that do not need to create pods.
  • User/service account identities where pod creation is not part of their function.
  1. Quick check for obviously over‑broad bindings
Problem indication:
Any of these broad subjects bound to roles that have create on pods from step 1.
  1. Verification after manual adjustments
After you manually edit Roles/ClusterRoles/Bindings (with kubectl edit or manifests), re-run:
Then re-check bindings for any remaining roles that still have pod create and confirm they are restricted only to the specific service accounts/users that truly require this capability.