Google rolling out automatic updates in August for Cloud vulnerability

Google said it is rolling out automatic updates to address a vulnerability affecting Authorized Networks and Cloud Run/Functions on Google Kubernetes Engine (GKE).

GKE provides its thousands of users with a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure. Kubernetes — developed by Google as an open-source container orchestration system — are used to deploy and manage applications, perform administration tasks, set policies, and monitor the health of workloads.

Greg Castle, security engineer with Google’s GKE Security, and GKE product manager Mahesh Narayanan said in a blog post that existing firewall rules allow the Kubernetes API server’s IP address to be reachable from the Cloud Run and Cloud Functions services. 

They noted that despite the issue, access alone was not enough for attackers, who also need calls to the API “to be authenticated and authorized using either Google Identity and Access Management or GKE role-based access control.” 

“To further improve security, we will soon limit that access to GKE-related services and block access from Cloud Run and Cloud Functions,” the two explained, noting that they have updated their product documentation and prioritized a plan to make engineering changes to GKE to restrict access to only GKE-related services.

“Those changes will roll out automatically to over 99% of our GKE customers by late August, and we will proactively reach out to the remaining customers to work on migration issues together.”

The two added that Google will migrate core GKE services that communicate with the API server onto a dedicated set of IP addresses and notify customers that currently rely on being able to communicate from other cloud services to the Kubernetes API server that the access will be removed. 

They noted that this applies to only 1% of all clusters. Instructions will be provided for those who need to “migrate to a new solution.”

Narayanan and Castle added that they will remove the existing firewall rule and introduce a targeted rule allowing only the dedicated set of IP addresses belonging to the core GKE services. 

“Once these steps are complete, 99% of private clusters won’t be accessible from Cloud Run or Cloud Functions, with no action required from those customers,” they said. 

“The remaining 1% will migrate on their own timeline as those customers need time to move their access to new solutions. Public clusters (where nodes have public IPs) will continue to be accessible from Google Cloud IPs as this is necessary for those nodes to communicate with the API server.”

The issue was first reported to Google by a security researcher on March 9. 

I would classify this vulnerability as MEDIUM severity as GKE requires authentication for most actions on their control plane API by default even with 0.0.0.0/0 (the entire internet) allowed in the authorized networks list.

— @[email protected] (@itspeterc) June 7, 2022

The researcher, who goes by Peter C on Twitter, said Google acknowledged that the vulnerability was something it knew about and planned to release a fix for later this year.

He explained that the issue revolves around the fact that a Cloud Function run in any Project and in any Organization “can bypass GKE authorized networks for a cluster in a different Project or Organization.”

Castle responded to the thread on Twitter, noting that they “added priority to an existing plan to improve authorized networks and have people working on it now.”

The change is complicated because a small set of customers depend on today's behavior, but we’re working through that with notifications and migration help. The functionality of today’s authorized networks feature is documented here: https://t.co/8zj3BPXVl3

— Greg Castle @[email protected] (@mrgcastle) June 7, 2022

“The change is complicated because a small set of customers depend on today's behavior, but we’re working through that with notifications and migration help,” he wrote. 

“All the standard authentication and RBAC/IAM authorization controls still apply, which as you note includes the ability to access a health status e.g. ‘OK’ and a version string as in the docs.”