# Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA

DevFeed: [Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA](<https://devfeed.tech/articles/kubernetes-v1-36-fine-grained-kubelet-api-authorization-graduates-to-ga-4539.md>)

Original publisher: [Read original article](<https://kubernetes.io/blog/2026/04/24/kubernetes-v1-36-fine-grained-kubelet-authorization-ga/>)

Author: Vinayak Goyal

Published: 2026-04-24T18:35:00Z

Content type: release

Language: en

Sources: [Kubernetes Blog](<https://devfeed.tech/sources/kubernetes-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Authorization](<https://devfeed.tech/topics/authorization.md>)

Tags: [apis](<https://devfeed.tech/tags/apis.md>), [auth](<https://devfeed.tech/tags/auth.md>), [containers](<https://devfeed.tech/tags/containers.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [observability](<https://devfeed.tech/tags/observability.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

Kubernetes v1.36 makes fine-grained kubelet API authorization generally available. It replaces broad nodes/proxy access for common monitoring and observability workloads with more precise, least-privilege permissions.

## Source excerpt

On behalf of Kubernetes SIG Auth and SIG Node, we are pleased to announce the graduation of fine-grained kubelet API authorization to General Availability (GA) in Kubernetes v1.36! The KubeletFineGrainedAuthz feature gate was introduced as an opt-in alpha feature in Kubernetes v1.32, then graduated to beta (enabled by default) in v1.33. Now, the feature is generally available and the feature gate is locked to enabled. This feature enables more precise, least-privilege access control over the kubelet's HTTPS API, replacing the need to grant the overly broad nodes/proxy permission for common monitoring and observability use cases. Motivation: the nodes/proxy problem The kubelet exposes an HTTPS endpoint with several APIs that give access to data of varying sensitivity, including pod listings, node metrics, container logs, and, critically, the ability to execute commands inside running containers. Prior to this feature, kubelet authorization used a coarse-grained model. When webhook authorization was enabled, almost all kubelet API paths were mapped to a single nodes/proxy subresource. This meant that any workload needing to read metrics or health status from the kubelet required nodes/proxy permission, the same permission that also grants the ability to execute arbitrary commands in any container running on the node. What's wrong with that? Granting nodes/proxy to monitoring agents, log collectors, or health-checking tools violates the principle of least privilege. If any of those workloads were compromised, an attacker would gain the ability to run commands in every container on the node. The nodes/proxy permission is effectively a node-level superuser capability, and granting it broadly dramatically increases the blast radius of a security incident. This problem has been well understood in the community for years (see kubernetes/kubernetes#83465), and was the driving motivation behind this enhancement KEP-2862. The nodes/proxy GET WebSocket RCE risk The situation is