Skip to main content

More Info:

The cluster-admin ClusterRole grants superuser access over the entire cluster. Bindings to it should be restricted to the minimum set of principals that strictly require it.

Risk Level

Critical

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. On any machine with kubectl access, list all ClusterRoleBindings that use the cluster-admin role and see their subjects:
  2. For each binding identified in step 1, inspect full details (including subject kinds and namespaces):
    Manually determine whether each non-system subject (Users, Groups, ServiceAccounts) truly requires cluster-wide superuser rights. Do not modify bindings whose name or subjects are system-prefixed (e.g., starting with system:) and are required for core components.
  3. For each subject that does not strictly require cluster-admin, design or select a least-privileged Role/ClusterRole that covers only the permissions it needs. For example, create a custom ClusterRole on any machine with kubectl access:
  4. Rebind each affected subject to the least-privileged (Cluster)Role instead of cluster-admin, using a new (Cluster)RoleBinding. Example for a ClusterRole and a user:
  5. After confirming that alternative bindings are in place and tested for each subject, remove the excessive cluster-admin bindings that are no longer required:
  6. Verify that no non-system principals remain bound to cluster-admin, on any machine with kubectl access:
On any machine with kubectl access:
  1. List all ClusterRoleBindings that use cluster-admin and review subjects
  1. For each non‑system binding you determine does NOT strictly require cluster-admin, remove the binding
    (Example using a placeholder name; replace with the real binding name you decided to remove.)
  1. (Optional) Create a least‑privilege ClusterRole and bind it instead of cluster-admin
    Example: read‑only access to pods in all namespaces.
Create a manifest file, e.g. readonly-pods-clusterrole.yaml:
Apply it:
Then bind it to the principal that previously had cluster-admin, for example a user:
(or use --group or --serviceaccount <namespace>:<sa-name> as appropriate.)
  1. Verification (on any machine with kubectl access)