# Do not classify Kubernetes nodes proxy get permission as read-only > Review what nodes/proxy get authority can reach before relying on API-server admission or audit as the complete control boundary. - Canonical URL: https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:46:45+00:00 - Modified: 2026-10-30T06:47:30+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Review what nodes/proxy get authority can reach before relying on API-server admission or audit as the complete control boundary. ## Potentially affected Kubernetes roles that grant get access to the nodes/proxy subresource. ## DSE recommendation Review nodes/proxy as a privileged kubelet access path rather than an ordinary read grant. ## Article 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](https://kubernetes.io/docs/concepts/security/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](https://kubernetes.io/docs/concepts/security/api-server-bypass-risks/) — Kubernetes. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Kubernetes API Server Bypass Risks - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/security/api-server-bypass-risks/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Do not classify Kubernetes nodes proxy get permission as read-only,” DSE Security, https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.