Capturing a Kubernetes cluster through a Google account

[or1k]

Orca Security has discovered (https://orca.security/resources/blog/sys-all-google-kubernetes-engine-risk-example/) a vulnerability in Google Kubernetes Engine (GKE). It allows attackers with a Google account to gain control of a Kubernetes cluster. The issue has been codenamed Sys:All. It is estimated that about 250,000 active GKE clusters are affected by the vulnerability.

The problem lies in a common misconception about the system:authenticated group in GKE. This is a special group that includes all authenticated objects, including users and service accounts. Many people believe that the group only includes authenticated users, when in fact it includes any Google account.

External attackers can use their Google OAuth 2.0 token to gain control of the cluster and then use it for a variety of purposes, including cryptomining, denial-of-service attacks, and theft of sensitive data. Additionally, this approach leaves no trace that can be traced back to a specific Gmail or Google Workspace account.

Various sensitive data is at risk, including JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and access to container registries, which could lead to malware injection into container images.

Google has already taken steps to address the flaw by disallowing the binding of the system:authenticated group to the cluster-admin role in GKE versions 1.28 and above. The company also recommends that users not bind the system:authenticated group to any RBAC (role-based access control) roles and check to see if their clusters are associated with the group.