Detections
Analytics
4.1.1 Ensure the cluster-admin ClusterRole is only used when required
Information
The RBAC cluster-admin ClusterRole grants full administrative authority across cluster resources and should be assigned only to approved users, groups, or service accounts with a documented operational need. For GKE Autopilot clusters, the control should focus on limiting RoleBinding and ClusterRoleBinding assignments to cluster-admin, not on removing or modifying the built in ClusterRole itself. GKE RBAC provides fine grained control over what users, groups, IAM service accounts, and Kubernetes ServiceAccounts can do inside the cluster.In GKE, Kubernetes RBAC uses Role, ClusterRole, RoleBinding, and ClusterRoleBinding objects to grant permissions to authenticated subjects, including users, groups, IAM service accounts, and Kubernetes ServiceAccounts. RBAC works alongside IAM in GKE, but Kubernetes RBAC is the appropriate mechanism for fine grained permissions on Kubernetes objects within a cluster or namespace. RBAC permissions are additive, so there are no deny rules to offset excessive access once a broad role is bound.
The cluster-admin ClusterRole grants permission to do anything on any resource in the cluster. When assigned through a ClusterRoleBinding, it provides cluster wide administrative access across all namespaces. When assigned through a RoleBinding, the ClusterRole is limited to the namespace specified in the binding, but it still grants the broad permissions of cluster-admin within that namespace. Where full administrative access is not explicitly required, define a narrower Role or ClusterRole that grants only the required API groups, resources, and verbs.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.
Solution
For each cluster-admin binding, replace broad access with a least privilege Role or ClusterRole that grants only the required API groups, resources, and verbs. Bind the replacement role to the approved user, group, IAM service account, or Kubernetes ServiceAccount first, validate access, and then remove the unnecessary cluster-admin binding.-
Identify all ClusterRoleBinding and RoleBinding objects that assign the cluster-admin ClusterRole, including both cluster wide and namespace level bindings.
-
Review each bound user, group, IAM service account, or Kubernetes ServiceAccount to confirm whether full administrative access is still required and documented.
-
Replace cluster-admin access where possible with a least privilege Role or ClusterRole that grants only the required API groups, resources, and verbs.
-
Bind and validate the replacement permissions before removing the existing cluster-admin binding to avoid disrupting administrative, platform, or automation workflows.
-
Remove only confirmed unnecessary bindings, and avoid modifying RBAC resources with the system: prefix unless explicitly required and validated because they support cluster functionality.
Impact:
Removing or modifying cluster-admin bindings without review can disrupt legitimate administrative, platform, or automation workflows. Before changing any binding, identify the subject, determine whether the access is still required, and replace broad access with least privilege RBAC where possible. Do not delete or modify RBAC resources with the system: prefix, because those resources support correct cluster functionality and improper changes can cause cluster instability or make the cluster inaccessible.
See Also
Item Details
Category: ACCESS CONTROL
References: 800-53|AC-6(2), 800-53|AC-6(5), CSCv7|4.3
Plugin: GCP
Control ID: 9ce2782711eb02e489e20ee2bda8d2b92b421642018467864bfd730e747aa074