Skip to main content

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

Medium

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Review current cluster Google Groups for GKE settings
    • On any machine with gcloud configured, run:
    • Decide whether Enabled is true and Security Group is set to the intended parent group (for example gke-security-groups@YOUR_DOMAIN).
  2. 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.
  3. 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.
  4. 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.
  5. 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 User subjects by removing or editing the existing bindings once you’ve confirmed equivalent group-based access is in place.
  6. 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 Group subjects (and not User) 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.
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.