A get permission on nodes/proxy looks harmless, but the Kubernetes docs say it is not read-only. It reaches the kubelet API, which can retrieve logs and execute commands in pods on that node, and the access bypasses audit logging and admission control. Treat it like cluster-admin on those nodes.
What the docs actually say
The RBAC good practices page states that users with access to the nodes/proxy sub-resource have rights to the kubelet API, which allows command execution on every pod on the nodes they have rights to. It adds that this access bypasses audit logging and admission control, so care should be taken before granting any rights to this resource.
The kubelet authentication page explains why a get can be dangerous. Some kubelet endpoints use websocket protocols over HTTP GET requests, which are authorized with the get verb. So get on nodes/proxy authorizes executing commands in any container on the node.
Why monitoring tools ask for it
Some monitoring and metrics agents request nodes/proxy to scrape kubelet endpoints. That is a common route by which the permission ends up in a ClusterRole nobody revisits. If a tool asks for it, ask what it really needs and whether a narrower path exists in your Kubernetes version.
The kubelet page also describes a fine-grained authorization feature (KubeletFineGrainedAuthz), listed as stable since Kubernetes v1.36 and enabled by default. It narrows checks for some endpoints, such as pods, healthz and configz, to specific subresources instead of the general proxy subresource. Check your cluster version and your tool's documentation before depending on it.
How to look for it
Search your ClusterRoles and Roles for nodes/proxy, and for wildcard resources that would include it. A wildcard on resources and verbs covers it too. In a shell:
kubectl get clusterroles -o yaml | grep -n "nodes/proxy"
kubectl get clusterrolebindings -o wide
Then map each match to the bindings that use it. The question to answer is who or what holds the permission, and whether that identity runs on a node you do not fully control.
What to do about it
- Remove nodes/proxy from any role that does not strictly need it.
- Prefer a narrower route to metrics where your tools support it.
- If you must keep it, bind it to a single service account, in a namespace with tight pod security, and note it in your access review.
- Put the binding on your periodic RBAC review list, since audit logs will not show the commands.
Safeguard cannot see inside your kubelet, so use cluster tooling for this check. What Safeguard can do is flag risky changes before they merge, through policies and gates on the manifests in your repositories.
Quick check
Is get on nodes/proxy safe because it is only get?
No. The docs say get permission on nodes/proxy is not read-only, because it can authorize command execution in containers on the node.
Sources
- Role Based Access Control Good Practices, Kubernetes docs
- Kubelet authentication and authorization, Kubernetes docs
Last reviewed: 19 October 2026.
