Skip to main content

More Info:

The proxy sub-resource of Node objects allows direct access to the kubelet API, bypassing usual controls. Restrict access to this sub-resource to trusted administrators only.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS EKS

Triage and Remediation

Remediation

Manual Steps

  1. List all ClusterRoles and Roles that can use the proxy subresource on Nodes
    • Run on: any machine with kubectl access
  2. Inspect each identified Role/ClusterRole to confirm the exact permissions
    • Run on: any machine with kubectl access
    • For each ClusterRole name from step 1:
    • For each Role NAMESPACE:NAME from step 1:
    • Manually review rules entries that reference nodes/proxy or resources: ["nodes"] with resourceNames: ["proxy"] and note who should legitimately have these permissions (typically only a small set of cluster admin roles).
  3. Identify which subjects are bound to those Roles/ClusterRoles
    • Run on: any machine with kubectl access
    • For each binding found, inspect subjects:
    • Decide which users/groups/service accounts truly require node proxy access (trusted administrators) and which do not.
  4. Restrict or remove unnecessary nodes/proxy access in Roles/ClusterRoles
    • Run on: any machine with kubectl access
    • For each Role/ClusterRole where non-admin use is not required, edit to remove the nodes/proxy permission (or scope it more narrowly if absolutely required):
      or
    • In the editor, delete the rules entries granting nodes/proxy where not needed, or move such permissions into a dedicated admin-only ClusterRole. Save and exit.
  5. Tighten bindings so only trusted administrators receive nodes/proxy rights
    • Run on: any machine with kubectl access
    • For roles that must retain nodes/proxy:
      • Ensure they are only bound to trusted admin users/groups/service accounts.
      • Edit bindings to remove non-admin subjects or move them to safer roles lacking nodes/proxy:
  6. Verify that only intended admin roles retain nodes/proxy access
    • Run on: any machine with kubectl access
    • Re-run discovery and confirm the remaining roles and bindings correspond only to trusted admins:
    • Manually confirm that any remaining roles with nodes/proxy are intentionally granted only to trusted administrator subjects.
What indicates a problem:
  • In step 1, any ClusterRole or Role that:
    • Lists resources: ["nodes", "nodes/proxy"] or includes nodes/proxy, and
    • Includes verbs such as proxy, *, or broad verbs (e.g., get, list, watch, create) that include proxy.
  • In step 3 and 4, those roles are:
    • Bound to broad subjects like system:authenticated, system:unauthenticated, system:masters, or large user groups.
    • Bound to application ServiceAccounts not intended to have direct kubelet access.
    • Used by default/built-in bindings in a way that grants many identities access to nodes/proxy.
These cases require human review to decide whether to narrow or remove nodes/proxy and/or re-scope the bindings to only trusted administrator identities.