A Google Kubernetes security flaw could let anyone with a Gmail account compromise your business

An abstract image of a lock against a digital background, denoting cybersecurity.
(Image Credit: TheDigitalArtist / Pixabay) (Image credit: Pixabay)

The Google Kubernetes Engine (GKE) carried a vulnerability which allowed pretty much anyone with a Gmail account to take over a Kubernetes cluster, experts have revealed.

Cybersecurity researchers from Orca broke the news, naming the vulnerability Sys:All and claiming that there are a quarter of a million active GKE clusters that could be vulnerable to the flaw. 

The problem lies in the fact that many people wrongly believe the system:authenticated group in Google Kubernetes Engine only includes verified and deterministic identities, researcher Ofir Yakobi told The Hacker News. In reality, any Google authenticated account will suffice.

Fixing the flaw

As explained in the report, the system:authenticated group includes authenticated entities, humans and service accounts alike. This means that a threat actor could use a Google OAuth 2.0 bearer token and gain control over the cluster. That control could subsequently be used to deploy all kinds of malware, move throughout the network, or steal sensitive data from the endpoints. 

What’s more, the victim organization wouldn’t be able to trace the attack back to a specific Gmail or Google Workspace account. The Hacker News reports that “numerous organizations” could be impacted by the findings, and different kinds of sensitive data could be put at risk. That includes JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and credentials to container registries.

Soon after breaking the news, Google came forward with steps to block the binding of the system:authenticated group to the cluster-admin role in GKE. These steps were applied in versions 1.28 onward. 

"To help secure your clusters against mass malware attacks that exploit cluster-admin access misconfigurations, GKE clusters running version 1.28 and later won't allow you to bind the cluster-admin ClusterRole to the system:anonymous user or to the system:unauthenticated or system:authenticated groups," the cloud giant said in its advisory.

More from TechRadar Pro

Sead is a seasoned freelance journalist based in Sarajevo, Bosnia and Herzegovina. He writes about IT (cloud, IoT, 5G, VPN) and cybersecurity (ransomware, data breaches, laws and regulations). In his career, spanning more than a decade, he’s written for numerous media outlets, including Al Jazeera Balkans. He’s also held several modules on content writing for Represent Communications.