Kubernetes v1.36 Made Me Rethink How We Authorize Kubelet Access

I was debugging a monitoring issue at 2 AM last week when it hit me: we'd granted our observability stack permissions that were way too broad on the kubelet API. The permission model was essentially "here, have access to everything kubelet-related" because we needed visibility into pod health. It felt wrong, but the alternatives seemed overcomplicated. Then I read about what shipped in Kubernetes v1.36, and I realized this exact problem—the one keeping me up—just got solved at the platform level.

The thing about Kubernetes is that it moves at its own pace. Features take years to mature from alpha to stable. That's usually frustrating when you're waiting for something, but in this case, I'm grateful. Fine-grained kubelet API authorization spent time in the oven, and what emerged is exactly what operators like me actually need.

The Authorization Problem We've Had All Along

For years, the kubelet's HTTPS API had a permission system that was more "sledgehammer" than "scalpel." If you needed to observe pod health or pull metrics, you either got the overly broad nodes/proxy permission or you didn't get anything at all. This created a security posture problem: every monitoring tool, every logging agent, every automated system that touched the kubelet got handed keys to way too many rooms in the house.

I've seen this play out in production. You grant permissions to Prometheus, and suddenly it has access to debug kubelet internals. You add a custom health checker, and it can do things it shouldn't. The principle of least privilege—something we're all supposed to care about—went out the window because the API didn't give us granular options.

Kubernetes v1.36 finally addresses this. The KubeletFineGrainedAuthz feature is now generally available, meaning it's no longer experimental. What this means in practice is that you can now grant permission to specific kubelet APIs without handing someone a master key.

What Changed—And Why It Matters

This feature graduated through the standard Kubernetes lifecycle: alpha in v1.32, beta in v1.33, stable in v1.36. That progression tells you the Kubernetes team tested this extensively. They found edge cases, refined the permission model, and incorporated feedback from operators running it in production.

The practical impact is significant. If you're running an observability stack, you can now grant it permission to query pod health and device status without also granting it access to authentication endpoints or debug interfaces. If you're running a custom controller that monitors device health—which is increasingly important with hardware accelerators—you can scope exactly what it can see.

Other Highlights Worth Attention

The v1.36 release includes 70 enhancements total, and a few beyond fine-grained authorization caught my attention. The resource health status feature expanding to beta is genuinely useful. We're running more workloads with specialized hardware—GPUs, accelerators, custom hardware—and having a native way to report health status means container orchestration can respond intelligently when hardware fails.

The workload-aware scheduling features entering alpha are interesting too, though I'm more cautious here. The idea of treating related pods as a single scheduling unit is powerful, but it adds complexity. I need to see this mature before adopting it in critical paths.

My Take: Progress That Feels Real

I appreciate that Kubernetes v1.36 solves real problems that operators face. Fine-grained authorization wasn't flashy or revolutionary, but it was necessary. This is what I value about the Kubernetes project: it listens to people running clusters at scale and iterates on the fundamentals.

The release notes mention that nothing is "guarded alone"—that maintainers, SIGs, contributors, and first-time contributors all pushed this forward. Reading that in the context of a feature that directly improves security posture feels right. Security isn't a feature added at the end; it's woven through the entire development process.

What I'm Doing Next

I'm planning to audit our kubelet RBAC rules and migrate to fine-grained authorization. It's the kind of foundational work that doesn't make it into status updates or sprint reviews, but it's the work that keeps production clusters secure and maintainable.

If you're running Kubernetes in production, I'd recommend reviewing which services touch the kubelet API and planning a migration to the new permission model. It's worth the effort.

Source: This post was inspired by "Kubernetes v1.36: ハル (Haru)" by Kubernetes Blog. Read the original article