Google Cloud Platform Security Advisory

Published: 01-19-2024



We have identified several clusters where users have granted Kubernetes privileges to the system:authenticated group, which includes all users with a Google account. These types of bindings are not recommended, as they violate the principle of least privilege and grant access to very large groups of users. See guidance under ‘What should I do’ for instructions on how to find these types of bindings.

Recently, a security researcher reported findings of clusters with RBAC misconfigurations through our vulnerability reporting program.

Google’s approach to authentication is to make authenticating to Google Cloud and GKE as simple and secure as possible without adding complex configuration steps. Authentication just tells us who the user is; Authorization is where access is determined. So the system:authenticated group in GKE that contains all users authenticated through Google’s identity provider is working as intended and functions in the same way as the IAM allAuthenticatedUsers identifier.

With this in mind we’ve taken several steps to reduce the risk of users making authorization errors with the Kubernetes built-in users and groups, including system:anonymous, system:authenticated, and system:unauthenticated. All of these users/groups represent a risk to the cluster if granted permissions. We discussed some of the attacker activity targeting RBAC misconfigurations and available defenses at Kubecon in November 2023.

To protect users from accidental authorization errors with these system users/groups, we have:

  • By default blocked new bindings of the highly privileged ClusterRole cluster-admin to User system:anonymous, Group system:authenticated, or Group system:unauthenticated in GKE version 1.28.
  • Built detection rules into Event Threat Detection (GKE_CONTROL_PLANE_CREATE_SENSITIVE_BINDING) as part of Security Command Center.
  • Built configurable prevention rules into Policy Controller with K8sRestrictRoleBindings.
  • Sent email notifications to all GKE users with bindings to these users/groups asking them to review their configuration.
  • Built network authorization features and made recommendations to restrict network access to clusters as a first layer of defense.
  • Raised awareness about this issue through a talk at Kubecon in November 2023.

Clusters that apply authorized networks restrictions have a first layer of defense: they cannot be attacked directly from the Internet. But we still recommend removing these bindings for defense in depth and to guard against errors in network controls.
Note there are a number of cases where bindings to Kubernetes system users or groups are used intentionally: e.g. for kubeadm bootstrapping, the Rancher dashboard and Bitnami sealed secrets. We have confirmed with those software vendors that those bindings are working as intended.

We are investigating ways we can further protect against user RBAC misconfiguration with these system users/groups through prevention and detection.

What should I do?

To prevent any new bindings of cluster-admin to User system:anonymous, Group system:authenticated, or Group system:unauthenticated users can upgrade to GKE v1.28 or later (release notes), where creation of those bindings are blocked.

Existing bindings should be reviewed following this guidance.


GKE on VMware

No updates at this time.


No updates at this time.

GKE on Azure

No updates at this time.

GKE on Bare Metal

No updates at this time.