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.
The Kubernetes API Server Bypass Risks documentation is the primary reference.
\nSome 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.
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.
\nDSE 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.
\nInspect 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.
\nHave 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.
\nRecord 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.
\nProposed 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Kubernetes API Server Bypass Risks documentation is the primary reference.\nSome 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhat exact kubelet operation does the requester need?\nWhich current grants expose the proxy subresource?\nWhat narrower documented permission meets the approved requirement?\nWhich owner accepts the remaining execution and observation boundary?\n\nDSE recommendation: review the reachable operation, not the verb label\nDSE 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.\nInspect 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.\nHave 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.\nRecord 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.\nVerification and evidence\nProposed 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.\nIf 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.\nOfficial references\n\nKubernetes API Server Bypass Risks — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Kubernetes API Server Bypass Risks](https://kubernetes.io/docs/concepts/security/api-server-bypass-risks/) documentation is the primary reference.\n\nSome 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- What exact kubelet operation does the requester need?\n\n- Which current grants expose the proxy subresource?\n\n- What narrower documented permission meets the approved requirement?\n\n- Which owner accepts the remaining execution and observation boundary?\n\n## DSE recommendation: review the reachable operation, not the verb label\n\nDSE 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.\n\nInspect 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.\n\nHave 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.\n\nRecord 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.\n\n## Verification and evidence\n\nProposed 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.\n\nIf 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.\n\n## Official references\n\n- [Kubernetes API Server Bypass Risks](https://kubernetes.io/docs/concepts/security/api-server-bypass-risks/) — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/", "url": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Do not classify Kubernetes nodes proxy get permission as read-only", "item": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/#article", "identifier": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/", "url": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/", "headline": "Do not classify Kubernetes nodes proxy get permission as read-only", "description": "Review what nodes/proxy get authority can reach before relying on API-server admission or audit as the complete control boundary.", "abstract": "Review what nodes/proxy get authority can reach before relying on API-server admission or audit as the complete control boundary.", "articleBody": "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.\nSource fact: documented behavior\nThe Kubernetes API Server Bypass Risks documentation is the primary reference.\nSome 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhat exact kubelet operation does the requester need?\nWhich current grants expose the proxy subresource?\nWhat narrower documented permission meets the approved requirement?\nWhich owner accepts the remaining execution and observation boundary?\n\nDSE recommendation: review the reachable operation, not the verb label\nDSE 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.\nInspect 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.\nHave 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.\nRecord 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.\nVerification and evidence\nProposed 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.\nIf 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.\nOfficial references\n\nKubernetes API Server Bypass Risks — Kubernetes.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:46:45+00:00", "dateModified": "2026-10-30T06:47:30+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/do-not-classify-kubernetes-nodes-proxy-get-permission-as-read-only/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Do not classify Kubernetes nodes proxy get permission as read-only" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 505, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — Kubernetes API Server Bypass Risks", "url": "https://kubernetes.io/docs/concepts/security/api-server-bypass-risks/" } } ] } }