More Info:
Cluster Administrators Should Leverage G Suite Groups And Cloud Iam To Assign Kubernetes User Roles To A Collection Of Users, Instead Of To Individual Emails Using Only Cloud Iam.Risk Level
MediumAddress
SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS GKE
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify and review current cluster Google Groups for GKE configuration
- On any machine with
gcloudaccess, run: - If
EnabledisfalseorSecurity Groupisnull, the cluster is not using Google Groups for GKE.
- On any machine with
-
Confirm existence and ownership of the intended security group
- In Google Admin Console (admin.google.com) under Directory → Groups, verify that the group you plan to use (for example,
gke-security-groups@YOUR_DOMAIN) exists, is owned by admins, and membership is managed according to your org’s access policies. - Decide which G Suite group will be used as the “security group” root for Google Groups for GKE.
- In Google Admin Console (admin.google.com) under Directory → Groups, verify that the group you plan to use (for example,
-
Decide whether to enable or adjust Google Groups for GKE on the cluster
- If the command in step 1 shows a different
securityGroupthan the one you intend to standardize on, or it is unset, plan the change:- Choose the primary security group email (for example,
gke-security-groups@YOUR_DOMAIN). - Ensure all teams understand that Kubernetes access will be granted via membership in sub‑groups of this security group.
- Choose the primary security group email (for example,
- If the command in step 1 shows a different
-
Configure or update the cluster to use Google Groups for GKE
- On any machine with
gcloudaccess, for an existing cluster: - For clusters created via IaC (Terraform, Deployment Manager), update the cluster resource to set the equivalent
security_group/authenticatorGroupsConfig.securityGroupfield, then apply via your normal IaC workflow.
- On any machine with
-
Review Kubernetes RBAC bindings to ensure they reference groups, not individual users
- On any machine with
kubectlaccess: - Inspect
subjectssections and confirm that:kind: Groupsubjects reference G Suite groups (e.g.dev-team@YOUR_DOMAIN) that are members of the security group.- Direct
kind: Usersubjects using individual email identities are minimized or removed where feasible.
- On any machine with
-
Verify configuration after changes
- Re-run the audit command from step 1 to confirm
EnabledistrueandSecurity Groupmatches the intended group: - Optionally, test with a user who is only a member of the relevant G Suite group (and not directly bound as a user) to confirm Kubernetes access is granted via group-based RBAC.
- Re-run the audit command from step 1 to confirm
Using kubectl
Using kubectl
kubectl cannot configure Google Groups for GKE or the cluster’s
authenticatorGroupsConfig; this must be set on the managed control plane via gcloud, the GCP console, or IaC. See the Manual Steps section for how to enable a security group on the cluster and then bind those groups with RBAC.Automation
Automation
- Save as
check_gke_google_groups.sh. chmod +x check_gke_google_groups.sh- Run, e.g.:
Google Groups for GKE enabled: false
orSecurity group:(empty ornull)
or- Line:
STATUS: PROBLEM - Google Groups for GKE not correctly configured.
--security-group configuration and require manual review and potential reconfiguration following the benchmark remediation.
