No user or group can read the nodes/proxy sub-resource

Check ID: rbac_minimize_node_proxy_subresource_access
Provider: Kubernetes
Service: rbac
Severity: HIGH
Categories: identity-access, cluster-security
Resource type: ClusterRoleBinding

What this check verifies

RBAC permissions to the nodes/proxy subresource are analyzed. Any user or group granted get, list, or watch via cluster-wide bindings is reported.

Risk

Access to nodes/proxy exposes the Kubelet API through the apiserver proxy, which can bypass audit and admission controls. An adversary could execute commands in pods, read sensitive data, and pivot across nodes, impacting confidentiality and integrity; broad access also risks node-wide service disruption.

Recommendation

Apply least privilege: avoid granting any verbs on nodes/proxy to users or groups. If access is unavoidable, limit it to trusted admins, scope narrowly, make it time-bound, and enforce separation of duties. Prefer namespace roles over cluster-wide bindings and review RBAC regularly as part of defense in depth.

Remediation

CLI
Terraform
Dashboard steps

kubectl delete clusterrolebinding <example_resource_name>

# Remove nodes/proxy access by defining the ClusterRole without that permission
resource "kubernetes_cluster_role" "<example_resource_name>" {
  metadata {
    name = "<example_resource_name>"
  }
  # Critical fix: no rule granting get/list/watch on "nodes/proxy" so subjects won't have that access
}

Identify the ClusterRoleBinding that grants the user/group access: in your RBAC list, locate the binding referencing a ClusterRole that includes resources: nodes/proxy with verbs get, list, or watch
Edit the ClusterRole: run kubectl edit clusterrole <example_resource_name>
In rules, remove any entry where resources includes nodes/proxy and verbs includes get, list, or watch; save and exit
If you cannot modify the role (shared role), delete the specific ClusterRoleBinding that attaches it to the user/group: kubectl delete clusterrolebinding <example_resource_name>

References

https://kubernetes.io/docs/concepts/security/rbac-good-practices/#access-to-proxy-subresource-of-nodes

Where this check fires

This check runs on every scheduled scan against your Kubernetes account. Findings appear at Cloud Security → Findings filterable by Check ID = rbac_minimize_node_proxy_subresource_access. To re-evaluate after a fix, hit Run now on the account’s schedule under Cloud Security → Schedules — the next scan re-checks this control and marks the finding fixed or keeps it persistent.

← Back to Kubernetes checks

No user or group can approve certificate signing requests Role or ClusterRole does not grant create permission on pods

​What this check verifies

​Risk

​Recommendation

​Remediation

​References

​Where this check fires

What this check verifies

Risk

Recommendation

Remediation

References

Where this check fires