DEV Community

kozhevniko
kozhevniko

Posted on

6,378,556 Hosts on Port 10250: The Cluster Node Interface That Assumes a Trusted Network

#exposuremanagement #containersecurity

6,378,556 Hosts on Port 10250: The Cluster Node Interface That Assumes a Trusted Network

Kubernetes distributes a control interface to every node in a cluster. The kubelet agent, which starts and manages containers on a host, exposes an HTTP API on port 10250 that the control plane uses to run commands, read logs and query node status. A query for port="10250" returned 6,378,556 matching assets on 23 September 2026.

Measurement scope

The query was executed once against the ZoomEye index on 23 September 2026: port="10250". It returned 6,378,556 matching assets. The unit is a listening service on that port at the recorded collection time, which includes cluster node interfaces and any other software bound to the same port.

Why a node interface is sensitive

The kubelet API is designed for the control plane. Its authentication and authorization behaviour is configurable, and a node configured to accept anonymous requests gives any client on the network the ability to perform the same operations the control plane performs: list pods, retrieve container logs, execute commands inside running containers and read the credentials that those containers are given.
That last capability matters most. Workloads in a cluster are commonly issued service account tokens and mounted secrets. A client that can execute inside a container inherits everything that container can reach, which often includes internal APIs, database credentials and cloud provider identity. The path from a node interface to an identity is short.
The component also sits outside what most teams monitor. The kubelet is not an application the team deployed, it is part of the platform, and its port is rarely in an application inventory. Cluster-level network policy tends to govern pod-to-pod traffic, while the node interface lives on the host network.

What 6,378,556 supports

The figure supports a scoping conclusion. A population of this size means that cluster node interfaces are reachable from untrusted networks in large numbers, and that automated scanning for this port will find candidates without any targeting decision on the attacker's part.
It also supports an inventory point. Port 10250 is registered to a specific purpose, and other software does bind it. A match count in the millions indicates broad exposure of whatever is listening, and the appropriate defensive response is to determine which of an organisation's own systems are in the set rather than to reason about the total.

What the count cannot support

The count does not indicate the authentication mode of any individual node. A kubelet that requires authenticated requests and a kubelet that permits anonymous access both listen on the same port, and the difference between them determines the impact of the exposure.
It does not indicate authorization configuration. Even with authentication in place, a permissive authorization mode can allow authenticated requests far beyond what the cluster intends.
It does not distinguish cluster nodes from standalone container hosts that expose a compatible interface, nor from services unrelated to Kubernetes that happen to be bound to the port.
It does not measure exploitation. No claim about compromise follows from a port count, and none is made here.

A practical test, run from inside

The useful version of this measurement is performed by the cluster operator rather than against the internet. From a machine outside the cluster network, attempt an unauthenticated request to the node interface and observe whether the API answers with node or pod information. Where it does, the node is published beyond its trust boundary and the response itself is the evidence.
Alongside that test, three checks belong in the same review. Confirm that the node interface is reachable only from the control plane and from any monitoring systems that require it, using network controls rather than application configuration. Confirm that anonymous authentication is disabled and that the authorization mode is set to a restrictive option. Confirm that workload credentials are short-lived and scoped, so that a single container read does not yield standing access to everything the cluster touches.

References

Top comments (0)