Skip to main content

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

Medium

Address

Security

Compliance 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

Manual Steps

  1. Identify and review current cluster Google Groups for GKE configuration
    • On any machine with gcloud access, run:
    • If Enabled is false or Security Group is null, the cluster is not using Google Groups for GKE.
  2. 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.
  3. Decide whether to enable or adjust Google Groups for GKE on the cluster
    • If the command in step 1 shows a different securityGroup than 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.
  4. Configure or update the cluster to use Google Groups for GKE
    • On any machine with gcloud access, for an existing cluster:
    • For clusters created via IaC (Terraform, Deployment Manager), update the cluster resource to set the equivalent security_group / authenticatorGroupsConfig.securityGroup field, then apply via your normal IaC workflow.
  5. Review Kubernetes RBAC bindings to ensure they reference groups, not individual users
    • On any machine with kubectl access:
    • Inspect subjects sections and confirm that:
      • kind: Group subjects reference G Suite groups (e.g. dev-team@YOUR_DOMAIN) that are members of the security group.
      • Direct kind: User subjects using individual email identities are minimized or removed where feasible.
  6. Verify configuration after changes
    • Re-run the audit command from step 1 to confirm Enabled is true and Security Group matches 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.
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.
How to run (any machine with gcloud access):
  1. Save as check_gke_google_groups.sh.
  2. chmod +x check_gke_google_groups.sh
  3. Run, e.g.:
Output interpretation (what indicates a problem):
  • Google Groups for GKE enabled: false
    or
  • Security group: (empty or null)
    or
  • Line: STATUS: PROBLEM - Google Groups for GKE not correctly configured.
These clusters are not leveraging G Suite Groups via the --security-group configuration and require manual review and potential reconfiguration following the benchmark remediation.

Additional Reading: