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

High

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS EKS
  • 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. List all clusterrolebindings that grant cluster-admin
    • Run on: any machine with kubectl access
  2. Inspect each binding’s subjects and note which are non-system users/groups
    • Run on: any machine with kubectl access
    • For each binding, identify subjects where:
      • kind is not Group, or
      • kind is Group and name is neither system:masters nor system:nodes.
  3. For each subject that should not have full cluster-admin, design or select a less-privileged role
    • Run on: any machine with kubectl access
    • Example: create a namespace-scoped admin role (adjust namespace and rules as needed):
    • Or create a ClusterRole if cluster-wide but still reduced permissions are required.
  4. Bind affected subjects to the new lower-privilege role/clusterrole
    • Run on: any machine with kubectl access
    • Example for a Role (namespace admin):
    • Example for a ClusterRole:
  5. Remove unnecessary cluster-admin bindings once replacement access is in place
    • Run on: any machine with kubectl access
    • To delete a whole binding that is no longer needed:
    • If a binding mixes system groups with non-system subjects, recreate it without the non-system subjects:
  6. Verify that only allowed subjects retain cluster-admin
    • Run on: any machine with kubectl access
    • Confirm the output is NO_CLUSTER_ADMIN_BINDINGS and no non-system subjects are reported.
On any machine with kubectl access:
  1. List all ClusterRoleBindings that grant cluster-admin
  1. Inspect each binding and its subjects to decide if cluster-admin is really required
    Replace <crb-name> with each name from step 1:
  1. (Optional) Create or bind to a lower-privilege role instead of cluster-admin
Example: create a constrained ClusterRole (edit rules as appropriate for your use case), save as limited-admin-clusterrole.yaml:
Apply it:
Then bind a user/group/serviceaccount to this new role, e.g. user@example.com, as limited-admin-<name>.yaml:
Apply it:
  1. Remove unnecessary cluster-admin ClusterRoleBindings
After you have confirmed that affected identities work with reduced privileges (or no access, if appropriate), delete each unnecessary binding:
Repeat for all ClusterRoleBindings that should no longer grant cluster-admin.
  1. Verification
Run the benchmark audit command again and ensure it prints NO_CLUSTER_ADMIN_BINDINGS (or only finds the allowed system groups):

Additional Reading: