Detections
Analytics
5.5.1 Use Google Groups to centrally manage Kubernetes RBAC access for GKE clusters
Information
Use Google Groups for RBAC to centrally manage Kubernetes RBAC access for GKE Autopilot clusters. Cluster administrators should assign Kubernetes RoleBinding and ClusterRoleBinding permissions to approved Google Groups rather than directly binding access to individual user email addresses.Group based RBAC improves access governance by allowing user onboarding, role changes, and offboarding to be managed through centralized group membership instead of editing Kubernetes RBAC bindings for each individual user. This reduces inconsistent one off permissions, simplifies access reviews, and helps ensure that access is removed when a user leaves the organization or changes responsibilities.
For GKE, the required gke-security-groups group acts as the security group used to evaluate Google Group membership for Kubernetes RBAC. Approved access groups should be nested under that security group and then referenced in Kubernetes RoleBinding or ClusterRoleBinding subjects.
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.
Solution
Enable Google Groups for RBAC when the audit shows that authenticatorGroupsConfig.enabled is not true, or when securityGroup is missing or incorrect. The required security group must be named gke-security-groups@DOMAIN, and approved access groups should be nested under that security group before they are referenced in Kubernetes RBAC bindings.gcloud container clusters update $CLUSTER_NAME \\
--location $LOCATION \\
--project $PROJECT_ID \\
--security-group=gke-security-groups@$DOMAIN
After Google Groups for RBAC is enabled, update Kubernetes RoleBinding and ClusterRoleBinding objects to reference approved Google Groups as kind: Group subjects. Replace direct User bindings with group based bindings where practical, while preserving required ServiceAccount bindings for workloads, controllers, and automation.
Review the RBAC table from the audit and remediate findings as follows:
-
Replace unnecessary SUBJECT_KIND values of User with approved Group subjects.
-
Confirm each Google Group referenced in RBAC is nested under gke-security-groups@DOMAIN.
-
Confirm group names match exactly because Google Group references in RBAC are case sensitive.
-
Remove direct user bindings only after validating that equivalent group based access is working.
-
Test access for representative users with kubectl auth can-i before removing existing access paths.
Rerun the audit commands and confirm that Google Groups for RBAC is enabled, the configured security group is correct, and Kubernetes RBAC bindings use approved Google Groups instead of direct individual user binding.
Impact:
Migrating to Google Groups for RBAC requires reviewing existing RoleBinding and ClusterRoleBinding subjects to replace direct individual user bindings with approved group based bindings. Group membership changes can take time to propagate because group information and user credentials are cached, so access changes might not take effect immediately. Avoid deleting the required security group or member groups without a migration plan because RBAC bindings that depend on those groups can fail and users can lose access.
See Also
Item Details
Category: ACCESS CONTROL, AUDIT AND ACCOUNTABILITY
References: 800-53|AC-2, 800-53|AC-3, 800-53|AC-6, 800-53|AC-6(1), 800-53|AC-6(7), 800-53|AU-9(4), CSCv7|16.2
Plugin: GCP
Control ID: 338a61535529e0bb25bb34ad14e99ab89564915ba99d2380fcbd66ff87c22b1d