Do not classify Kubernetes nodes proxy get permission as read-only

Bottom line: Escalate a proposed get grant on nodes/proxy for a dedicated access review. Require the requested kubelet operation to be identified rather than approving it from the verb’s everyday meaning.

Source fact: documented behavior

The Kubernetes API Server Bypass Risks documentation is the primary reference.

Some kubelet endpoints use WebSockets over HTTP GET, so get permission on nodes/proxy can authorize command execution in containers on the node. Direct kubelet API access is outside Kubernetes API-server admission processing and is not recorded by Kubernetes API audit logging.

What the source does not establish

This article identifies a permission boundary; it supplies no exploit procedure or approval to execute commands on a shared node. It does not establish the complete logging available from other components or claim that every similarly named read permission has the same behavior. Keep workload-creation and namespace-admission reviews separate.

Applicability questions

• What exact kubelet operation does the requester need?
• Which current grants expose the proxy subresource?
• What narrower documented permission meets the approved requirement?
• Which owner accepts the remaining execution and observation boundary?

DSE recommendation: review the reachable operation, not the verb label

DSE recommends treating the proxy grant as a privileged exception until the required operation and a narrower alternative have been reviewed. Write the intended operational task in plain language before choosing role rules. Ask the requester to identify why an ordinary API observation is insufficient.

Inspect the effective grant through approved administrative tools, including the subjects that inherit it. Keep the role definition and binding population together. Separate a diagnostic agent’s stated read purpose from the operations its actual authorization permits. Do not accept a display label as the authorization review.

Have the cluster owner consult the installed release’s documented granular permissions before proposing a replacement. Review the exact required operation and denied operations together. Avoid inventing a subresource name or broadening a role until the task happens to work. Preserve service continuity through the supported access-change procedure.

Record the observation plan explicitly. Ask which evidence will show use of the approved path and where the responsible operator should investigate a discrepancy. Do not promise API-server admission or audit coverage for a route outside that boundary. Revisit the exception when the consuming tool or its required endpoint changes.

Verification and evidence

Proposed verification: begin with an offline review of a sanitized role and binding fixture. Mark any nodes/proxy grant and compare it with the written task. Have the platform owner identify the supported replacement or explain why the exception remains necessary.

If a runtime check is required, use a disposable node and harmless workload under a separately approved plan. Exercise only named authorized and excluded operations; do not probe unrelated endpoints. Retain the effective role, test identity, actual authorization results and observations from the agreed logging sources. Report an untested path as unresolved rather than describing the role as read-only.

Official references

• Kubernetes API Server Bypass Risks — Kubernetes.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.