Skip to main content

More Info:

The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.

Risk Level

Critical

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)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. On any machine with kubectl access, list all ClusterRoleBindings that grant cluster-admin and see who they bind to:
  2. For each binding you found, display full details (to distinguish system vs non-system subjects):
    Manually review each subject; plan to keep bindings only if they are:
    • Group with name system:masters, or
    • other system: prefixed subjects that are required for core components.
  3. For any non-system user/group/service account that does not strictly require cluster-admin, design or select a least-privileged Role/ClusterRole that matches its actual needs. For example, to create a narrower ClusterRole for read-only access to pods and services:
  4. Bind the least-privileged role to the principal instead of cluster-admin, adjusting kind/name/namespace as appropriate:
    • Example for a user:
    • Example for a service account:
  5. After confirming that the replacement binding(s) exist and are correct, remove the excessive cluster-admin binding(s), being careful not to delete required system: bindings or the system:masters mapping:
  6. Verification (on any machine with kubectl access): rerun the audit, which should now return NO_CLUSTER_ADMIN_BINDINGS or only allowlist subjects:
On any machine with kubectl access:
  1. List all ClusterRoleBindings that grant cluster-admin and inspect subjects:
For deeper inspection of a specific binding:
  1. For each non-system subject that does not truly require cluster-admin, create or select a least‑privileged (Cluster)Role and bind to that instead.
Example: create a narrowly scoped ClusterRole (edit as appropriate):
Bind the principal to this least‑privileged ClusterRole:
  1. Remove excessive cluster-admin bindings for non-system principals (do NOT delete any system: bindings or the system:masters group):
Repeat for each binding you have replaced with a least‑privileged alternative.
  1. Verification (on any machine with kubectl access):

Additional Reading: