On July 26th, Google sent their Google Kubernetes Engine (GKE) customers an email about the fact that they identified an unauthenticated “read-only” port (10255) in the Kubelet server, which could result in a potential data leak or compromise, if not turned off. Google also noted that to remedy this, they have put a “phase out” plan in place that disables port 10255 by default for new clusters created on GKE version 1.32 and higher, and on future GKE versions, port 10255 will be completely disabled with no option to enable it. 

To improve the security of GKE clusters, Google however recommends organizations to proactively disable port 10255. Also, since the updates to GKE 1.32 will not actually disable any ports that are currently already open, it’s important that cluster administrators find all 10255 open ports, and disable them if they’re not in use.

The Orca Research Pod found that the issue is widespread: From scans on the Orca Platform we see that the large majority (87%) of organizations running GKE have at least one open read-only port 10255 on their Kubelet Server. 

Although we don’t think this is cause for panic since it’s quite hard for attackers to exploit these ports, and the “reward” for the attacker would be quite low, it’s certainly best practice to ensure there are no open 10255 ports in your environment, especially if they are exposed. In this blog, we explain what a GKE read-only port is, what the security risk is, and how to find and disable any 10255 open ports.

What is a Kubelet?

A kubelet is the primary node agent that runs on each node in the Kubernetes cluster. In short, a kubelet is what makes a VM into a Kubernetes node. It is responsible for managing the lifecycle of containers, ensuring they are running and healthy, and exposing data to the API server (the “brain” of the cluster).

What is a GKE read-only port? 

In Google Kubernetes Engine (GKE), the kubelet read-only port is a deprecated and insecure feature in Kubernetes that provided unauthenticated HTTP access to retrieve basic information about the node and its running pods. The default port for this is 10255, but Google is now recommending to disable this port and switch workloads to use the more secure port 10250 instead.

What’s the security risk of a read-only port?

Google’s recent communication about the unsecured read-only port being open (on localhost) by default raises some security concerns. The read-only port exposes sensitive information about the node and the running pods, including status and metrics. 

Although limiting the port to localhost reduces the risk of external attacks, local processes on the node and pods with specific configuration (pods running on the node and have the hostNetwork configuration set to true) can still access this information. This presents a potential risk if an attacker gains local access to the node or said pod through other vulnerabilities or exploits, enabling them to gather information that could aid further attacks or privilege escalation in the cluster/account.

How to disable a GKE read-only port

GCP provides a detailed guide with instructions on how to disable the GKE read-only port. 

Google advises to migrate any applications currently using port 10255 to the more secure Kubelet port 10250. Once all clusters in your environment are no longer using port 10255, you can implement a custom org policy to prevent future use of this port on new and existing clusters.

How the Orca Platform helps

The Orca Cloud Security Platform automatically detects enabled Kubernetes read-only ports and warns against this risk. Orca generates these alerts for any read-only ports found on Google Kubernetes Engine, but also on Amazon Elastic Kubernetes Service (Amazon EKS) and Azure Kubernetes Service (AKS).

About Orca Security

We’re on a mission to provide the industry’s most comprehensive cloud security platform while adhering to what we believe in: frictionless security and contextual insights, so you can prioritize your most critical risks and operate in the cloud with confidence.

Unlike other solutions, Orca is agentless-first and fully deploys in minutes with 100% coverage, providing wide and deep visibility into risks across every layer of your cloud estate. This includes cloud configurations, container images, the Kubernetes control plane, as well as your applications. Orca combines all this information in a Unified Data Model to effectively prioritize risks and recognize when seemingly unrelated issues can be combined to create dangerous attack paths. To learn more, see the Orca Platform in action.