The kubelet read-only port is a deprecated unauthenticated HTTP interface, commonly exposed on port 10255. It can return basic node and pod information without proper authentication, which creates unnecessary exposure. Modern deployments should disable it and use the secured kubelet port instead.
What the kubelet read-only port is used for
The kubelet read-only port was historically a convenience interface for retrieving basic node and pod details from a Kubernetes node without authentication. It exposed status-style information, not full control, but that still made it a meaningful visibility boundary that modern clusters should treat carefully.
Because it is unauthenticated, the port can reveal workload names, node state, and other operational details that help an operator, or an attacker, understand the cluster. That is why the secure kubelet port is the expected replacement, and why exposure of 10255 is usually considered unnecessary in hardened environments.
Why it mattered operationally
In practice, the read-only port existed as an easy status endpoint for node inspection and troubleshooting. The problem is that “read only” does not mean “safe to expose,” especially when the data returned can help map the cluster’s internal structure or confirm what is running on a node.
Its usefulness was always narrow, because the same operational need can usually be met through authenticated Kubernetes APIs, node-level tooling, or log and metrics pipelines that preserve access control. That makes the port more of a legacy compatibility surface than a modern management interface.
Security implications of unauthenticated node exposure
An unauthenticated kubelet endpoint weakens the normal trust boundary around node metadata. Even limited visibility can assist reconnaissance, reveal pod placement, or confirm where sensitive workloads live, which is why kubelet exposure is often discussed alongside cluster hardening and node access control. Guidance from the Kubernetes NHI Security Guide is relevant here because kubelet exposure sits inside the broader problem of Kubernetes workload and node trust.
In security terms, the issue is not just what the endpoint returns, but what it enables when combined with other weaknesses. A public read-only port can make enumeration easier, reduce attacker effort during discovery, and expose enough structure to support later abuse of the cluster control plane or node perimeter.
Modern handling and secure replacement
The correct posture is to disable the read-only port and rely on the authenticated kubelet port and Kubernetes-native access paths instead. That keeps node data behind identity-aware controls and aligns with the expectation that node operations should be observable only through managed, authorized channels. Kubernetes workload identity and kubelet access are part of the same hardening story, because the cluster should distinguish between operational access and anonymous exposure.
Where teams still depend on the port for legacy tooling, the better answer is to migrate that tooling rather than preserve the exposure. Disabling 10255 is usually a low-friction hardening change with high security value, especially in multi-tenant or internet-facing environments.
Risk and Threat Considerations
Exposed kubelet read-only ports create avoidable reconnaissance surface. Even if the endpoint cannot directly change state, it can still leak information that helps attackers identify nodes, infer deployed workloads, and plan follow-on activity against the cluster or adjacent infrastructure.
Failure mechanism: Anonymous access to node metadata bypasses the normal authentication and authorization checks that should gate operational visibility, allowing enumeration of pods and node details that should not be public.
Impact: The exposure can simplify attack planning, increase the chance of targeted abuse, and widen the blast radius of other cluster weaknesses by giving adversaries a clearer map of the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Covers authenticated service-to-service node access instead of anonymous kubelet exposure. |
| Recommendation — Use IA-9 to require authenticated kubelet access and eliminate unauthenticated node endpoints. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports reducing exposed management surfaces and tightening access paths to node services. |
| Recommendation — Remove the read-only port and restrict kubelet access to approved management channels. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The port is an unauthenticated interface that weakens node access control. |
| Recommendation — Disable anonymous kubelet exposure and enforce authenticated node access. | ||
Practitioner Guidance
What to watch for: Treat any reachable kubelet read-only port as an unnecessary exposure unless you have a tightly justified, temporary exception. Review node firewalling, cloud security groups, and cluster bootstrap defaults so 10255 is not left open by inherited configuration.
Practitioner takeaway: If the port is still present, the safest assumption is that it should be removed, not monitored as a permanent control surface.
Related resources from NHI Mgmt Group
- Why does an open kubelet read-only port create risk in Kubernetes environments?
- What are the signs that a Kubernetes read-only port is a governance problem rather than a low-priority finding?
- How should security teams harden SSH without relying on port changes alone?
- What is the difference between changing port 22 and real SSH hardening?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
