Detections
Analytics

4.1.6 Avoid granting cluster admin level access through the system:masters group

Information

The special Kubernetes group system:masters should not be used to grant cluster admin level access to users, groups, or service accounts. In GKE, administrative access should be granted through explicit RBAC bindings and limited to the minimum permissions required. The system:masters group is a default Kubernetes group, and adding custom subjects to it gives those subjects access to do anything to any resource in the cluster.

The system:masters group is bound to the cluster-admin ClusterRole by default to support system functionality. Adding users, groups, or service accounts to this group grants unrestricted cluster administrator access across all namespaces and resources. This bypasses normal least privilege role design and can make access harder to review, reduce, or replace with narrower RBAC controls.

Do not use system:masters for routine administrative access. Where full administrative access is truly required, use an explicit ClusterRoleBinding to the built in cluster-admin ClusterRole and document the operational need. For most use cases, create a narrower Role or ClusterRole that defines only the required API groups, resources, and verbs. Google also recommends avoiding default roles and groups, avoiding broad cluster-admin bindings, and applying least privilege.

Solution

Remediate custom system:masters usage by replacing it with explicit, auditable RBAC assignments. Do not remove the default cluster-admin ClusterRoleBinding to system:masters, because it supports Kubernetes system functionality. Instead, remove custom paths that add users, groups, service accounts, or client certificates to system:masters, and grant required access through least privilege Roles, ClusterRoles, RoleBindings, or ClusterRoleBindings.

 -

Remove any custom RoleBinding or ClusterRoleBinding that references system:masters, after confirming it is not a required system binding

 -

Remove system:masters from identity provider mappings, certificate subject groups, or other external authentication sources used for cluster access

 -

Replace required administrative access with explicit RBAC bindings to cluster-admin only where full cluster access is justified

 -

For most users, groups, service accounts, and automation, create narrower roles that define only the required API groups, resources, and verbs

Impact:

Avoiding system:masters may require replacing legacy or bootstrap access patterns with explicit RBAC bindings. Users or automation that previously relied on system:masters might lose unrestricted access until the required Role, ClusterRole, RoleBinding, or ClusterRoleBinding is created and validated. This reduces the risk of uncontrolled cluster admin access.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: ACCESS CONTROL

References: 800-53|AC-6(2), 800-53|AC-6(5), CSCv7|4

Plugin: GCP

Control ID: a756b306090df404a14873b1efc9c412725c8bd5cc335ae81328bc4e1ed942be