Skip to main content

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

Remediation

Manual Steps

  1. Identify who can create Pods in each namespace
    Run on any machine with kubectl access:
    To list all subjects with create on pods (Role/RoleBinding + ClusterRole/ClusterRoleBinding):
    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:
    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:
    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:
    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:
    For specific high‑risk identities (e.g. human admins, CI service accounts), validate explicitly:
  6. Optionally test by simulating Pod creation attempts
    For a sampled set of users/service accounts:
    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:

Using kubectl

Run these commands from any machine with kubectl access.

1. Find who can create pods cluster-wide

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 ClusterRoles:
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:

2. Find who can create pods in each namespace

List all Roles that allow pod creation:
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 Roles:
For a specific namespace with many workloads (e.g. prod):
Problem indication:
  • RoleBindings that attach pod-creating Roles 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):
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.