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
CriticalAddress
SecurityCompliance 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
Remediation
Manual Steps
Manual Steps
-
On any machine with kubectl access, list all ClusterRoleBindings that grant
cluster-adminand see who they bind to: -
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:
Groupwith namesystem:masters, or- other
system:prefixed subjects that are required for core components.
-
For any non-system user/group/service account that does not strictly require
cluster-admin, design or select a least-privilegedRole/ClusterRolethat matches its actual needs. For example, to create a narrowerClusterRolefor read-only access to pods and services: -
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:
- Example for a user:
-
After confirming that the replacement binding(s) exist and are correct, remove the excessive
cluster-adminbinding(s), being careful not to delete requiredsystem:bindings or thesystem:mastersmapping: -
Verification (on any machine with kubectl access): rerun the audit, which should now return
NO_CLUSTER_ADMIN_BINDINGSor only allowlist subjects:
Using kubectl
Using kubectl
On any machine with kubectl access:For deeper inspection of a specific binding:Bind the principal to this least‑privileged ClusterRole:Repeat for each binding you have replaced with a least‑privileged alternative.
- List all ClusterRoleBindings that grant
cluster-adminand inspect subjects:
- 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.
- Remove excessive
cluster-adminbindings for non-system principals (do NOT delete anysystem:bindings or thesystem:mastersgroup):
- Verification (on any machine with kubectl access):
Automation
Automation

