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

Kubernetes v1.36 marks an important milestone for cluster security: fine-grained kubelet API authorization has reached General Availability (GA). This feature, which began as an alpha experiment in v1.32 and moved to beta in v1.33, is now production-ready and will be enabled by default in new clusters. For teams managing Kubernetes at scale, this graduation matters because it gives you precise control over who can do what on individual nodes—closing a significant security gap that’s existed in Kubernetes for years.

To understand why this feature matters, let’s look at what kubelet does. Every node in your cluster runs a kubelet process that manages containers, handles health checks, and exposes an API for the control plane and other components to interact with the node itself. Previously, if you wanted to restrict access to the kubelet API, your options were limited: either allow full access or block it entirely. With fine-grained authorization, you can now enforce detailed policies—for example, allowing the metrics scraper to read resource usage but not restart containers, or letting your log collector read logs without granting it permission to execute commands. This is implemented through standard Kubernetes RBAC (Role-Based Access Control) rules, so it integrates seamlessly with your existing authorization framework.

Technically, the feature works by intercepting kubelet API requests and evaluating them against authorization policies you define in your cluster. When a request comes in—whether it’s from a pod, a node, or an external service—the kubelet checks your RBAC rules to determine if that principal has permission to perform that specific action. This evaluation happens at the API level, not at the container runtime level, which means it’s consistent and auditable. The granularity extends to specific operations: you can permit nodes/log access while denying nodes/exec, or allow reading metrics while restricting nodes/proxy requests. In practice, this is particularly valuable in multi-tenant clusters or when running privileged workloads that need node-level access—you can grant just the permissions they need rather than a broad blanket of trust.

Real-world scenarios where this becomes essential include security scanning tools that need to inspect container images and read logs from nodes, monitoring agents that must collect metrics but shouldn’t restart workloads, and admission controllers or security operators that require specific node introspection capabilities. If you’re running a managed service platform where different teams deploy on the same cluster, fine-grained kubelet authorization lets you enforce blast radius limits: a team’s workload can’t accidentally (or maliciously) interfere with another team’s node operations. With GA status, this feature is now fully supported and tested across the ecosystem, making it safe to adopt as part of your standard cluster hardening practices. If you’re already using Kubernetes 1.36 or planning to upgrade, enabling this feature should be near the top of your security checklist.