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
MediumAddress
SecurityCompliance Standards
- CIS EKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all ClusterRoles and Roles that can use the
proxysubresource on Nodes- Run on: any machine with
kubectlaccess
- Run on: any machine with
-
Inspect each identified Role/ClusterRole to confirm the exact permissions
- Run on: any machine with
kubectlaccess - For each ClusterRole name from step 1:
- For each Role
NAMESPACE:NAMEfrom step 1: - Manually review
rulesentries that referencenodes/proxyorresources: ["nodes"]withresourceNames: ["proxy"]and note who should legitimately have these permissions (typically only a small set of cluster admin roles).
- Run on: any machine with
-
Identify which subjects are bound to those Roles/ClusterRoles
- Run on: any machine with
kubectlaccess
- For each binding found, inspect subjects:
- Decide which users/groups/service accounts truly require node proxy access (trusted administrators) and which do not.
- Run on: any machine with
-
Restrict or remove unnecessary
nodes/proxyaccess in Roles/ClusterRoles- Run on: any machine with
kubectlaccess - For each Role/ClusterRole where non-admin use is not required, edit to remove the
nodes/proxypermission (or scope it more narrowly if absolutely required):or - In the editor, delete the
rulesentries grantingnodes/proxywhere not needed, or move such permissions into a dedicated admin-only ClusterRole. Save and exit.
- Run on: any machine with
-
Tighten bindings so only trusted administrators receive
nodes/proxyrights- Run on: any machine with
kubectlaccess - 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:
- Run on: any machine with
-
Verify that only intended admin roles retain
nodes/proxyaccess- Run on: any machine with
kubectlaccess - Re-run discovery and confirm the remaining roles and bindings correspond only to trusted admins:
- Manually confirm that any remaining roles with
nodes/proxyare intentionally granted only to trusted administrator subjects.
- Run on: any machine with
Using kubectl
Using kubectl
- In step 1, any
ClusterRoleorRolethat:- Lists
resources: ["nodes", "nodes/proxy"]or includesnodes/proxy, and - Includes
verbssuch asproxy,*, or broad verbs (e.g.,get,list,watch,create) that includeproxy.
- Lists
- 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.
- Bound to broad subjects like
nodes/proxy and/or re-scope the bindings to only trusted administrator identities.Automation
Automation

