Google account misconfiguration lets any gmail account control your cluster.

Cybersecurity researchers have discovered a loophole impacting Google Kubernetes Engine (GKE) that could be potentially exploited by threat actors with a Google account to take control of a Kubernetes cluster. As many as 250,000 active GKE clusters in the wild are estimated to be susceptible to the attack vector.

The system

The authenticated group is a special group that includes all authenticated entities, counting human users and service accounts. As a result, this could have serious consequences when administrators inadvertently bestow it with overly permissive roles.

Specifically, an external threat actor in possession of a Google account could misuse this misconfiguration by using their own Google OAuth 2.0 bearer token to seize control of the cluster for follow-on exploitation such as lateral movement, crypto mining, denial-of-service, and sensitive data theft.

To make matters worse, this approach does not leave a trail in a manner that can be linked back to the actual Gmail or Google Workspace account that obtained the OAuth bearer token.

All have been found to impact numerous organisations, leading to the exposure of various sensitive data, such as JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and credentials to container registries, the last of which could then be used to trojan container images.

Following responsible disclosure to Google, the company has taken steps to block the binding of the system: authenticated group to the cluster-admin role in GKE versions 1.28 and later.

In a separate security bulletin, Google Cloud said granting Kubernetes privileges to the system: authenticated group violates the principle of least privilege and grants access to very large groups of users.

The company also said it has "built detection rules into Event Threat Detection (GKE_CONTROL_PLANE_CREATE_SENSITIVE_BINDING) as part of Security Command Centre" and that it has "built configurable prevention rules into Policy Controller with K8sRestrictRoleBindings."

Finally, email notifications have been sent to all GKE users with bindings to these users/groups, asking them to review their configuration.

Google is also recommending users not bind the system: authenticated group to any RBAC roles, as well as assess whether the clusters have been bound to the group using both ClusterRoleBindings and RoleBindings and remove any unsafe bindings.

While there is no public record of a large-scale attack utilising this method, it could be only a matter of time, necessitating that users take appropriate steps to secure their cluster access controls.

Found this interesting? Stay connected with Logixal at – info@ logixal.co.uk for the latest in tech and security.