More Info:
Bind Kubernetes RBAC roles to Google Groups so cluster access is managed centrally through group membership. This simplifies and secures access administration versus per-user bindings.Risk Level
MediumAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Review current cluster Google Groups for GKE settings
- On any machine with gcloud configured, run:
- Decide whether
EnabledistrueandSecurity Groupis set to the intended parent group (for examplegke-security-groups@YOUR_DOMAIN).
- On any machine with gcloud configured, run:
-
If not enabled, decide on the security group and enable it (control-plane impact)
- Identify or create, in Google Workspace / Cloud Identity, a parent group (e.g.
gke-security-groups@YOUR_DOMAIN) and document its purpose and membership policy (who can be added, who can administer it). - On any machine with gcloud, update the existing cluster:
- Be aware: updating this may change how users authenticate/authorize; plan and execute during a maintenance window if needed.
- Identify or create, in Google Workspace / Cloud Identity, a parent group (e.g.
-
Inventory existing RBAC bindings that use direct users vs groups
- On any machine with kubectl access:
- Use this output to identify principals that should instead be granted access via Google Groups.
- On any machine with kubectl access:
-
Design target Google Groups-to-RBAC mapping
- For each set of permissions you want to manage centrally (e.g. “cluster-admins”, “namespace-owners”, “read-only”), define a Google Group email that will be used as the RBAC subject (e.g.
gke-cluster-admins@YOUR_DOMAIN). - Map:
- Google Group → Kubernetes (Cluster)Role(s) → Scope (cluster or namespace).
- Ensure membership of these groups is managed through your standard identity governance process.
- For each set of permissions you want to manage centrally (e.g. “cluster-admins”, “namespace-owners”, “read-only”), define a Google Group email that will be used as the RBAC subject (e.g.
-
Implement or update RBAC bindings to use Google Groups
- On any machine with kubectl access, for each intended mapping, create or update bindings referencing the Google Group (subject
kind: Group,name: GROUP_EMAIL). Example (adjust names/namespaces as needed): - Gradually phase out direct
Usersubjects by removing or editing the existing bindings once you’ve confirmed equivalent group-based access is in place.
- On any machine with kubectl access, for each intended mapping, create or update bindings referencing the Google Group (subject
-
Verify configuration and access behavior
- Re-run the cluster describe command on any machine with gcloud to ensure Google Groups for GKE is enabled and pointing at the correct security group:
- On any machine with kubectl access, confirm that RBAC bindings now reference
Groupsubjects (and notUser) for intended access paths: - Optionally, have a test user who is only a member of the appropriate Google Group log in and confirm they receive the expected level of access and no more.
- Re-run the cluster describe command on any machine with gcloud to ensure Google Groups for GKE is enabled and pointing at the correct security group:
Using kubectl
Using kubectl
kubectl cannot configure Google Groups for GKE or the cluster’s
--security-group setting; those are managed in the GKE control plane via gcloud, console, or IaC. To remediate this finding, follow the guidance in the Manual Steps section, using the cloud provider tools to enable Google Groups for GKE and then create the appropriate RBAC bindings.Automation
Automation

