5.1.14 Ensure that access to the Kubelet API uses fine-grained subresources instead of nodes/proxy where possible

Information

Where principals require access to specific Kubelet API endpoints such as /healthz, /pods, or /configz, use the fine-grained RBAC subresources nodes/healthz, nodes/pods, and nodes/configz instead of granting nodes/proxy access.

The nodes/proxy subresource grants access to all Kubelet API endpoints that do not have a dedicated subresource, including dangerous endpoints which allow arbitrary command execution in containers on the node.

Prior to Kubernetes v1.36, agents that only needed to check node health or list running pods were forced to use nodes/proxy, granting them unnecessary access to these dangerous endpoints. Kubernetes v1.36 introduced fine-grained subresources ( nodes/healthz, nodes/pods, nodes/configz ) that allow access to specific Kubelet API endpoints without granting access to command execution endpoints. Granting nodes/proxy to monitoring agents, health checkers, or other principals that do not require exec access violates the principle of least privilege and increases the blast radius if a service account token is compromised.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

For each principal that does not require access to command execution endpoints, create a ClusterRole granting only the required fine-grained subresources.

Impact:

Principals that currently rely on nodes/proxy to access /healthz, /pods, or /configz endpoints will need their RBAC bindings updated. During mixed-version rollouts where some kubelets are running versions prior to v1.36, both the fine-grained subresource and nodes/proxy may need to be granted temporarily to avoid access failures.

See Also

https://workbench.cisecurity.org/benchmarks/26886