How does Kubernetes v1.36 fine-grained kubelet API authorization improve least privilege for monitoring agents?
Quick Answer
Kubelet API requests can now be authorized against specific node subresources such as `nodes/metrics`, `nodes/stats`, and `nodes/pods` instead of broadly granting `nodes/proxy`. This lets monitoring agents scrape what they need without receiving a much wider kubelet API permission.
Detailed Answer
Before fine-grained kubelet authorization, many monitoring agents received nodes/proxy access because that was the practical way to reach kubelet endpoints. That permission is broad and can expose more kubelet API surface than a metrics scraper needs.
In Kubernetes v1.36, fine-grained kubelet authorization is GA and always active. The kubelet first checks a specific subresource for common paths, then falls back to nodes/proxy for compatibility. This creates a migration path: existing charts continue to work, while new or hardened deployments can move to scoped permissions.
A production migration should inventory ClusterRoles that grant nodes/proxy, identify why each workload needs kubelet access, and replace broad rules with subresources such as nodes/metrics and nodes/stats where possible. Then use admission policy or policy-as-code to flag new broad grants. Watch for mixed-version clusters and third-party Helm charts that have not yet adopted the new RBAC model.
Code Example
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: monitoring-agent rules: - apiGroups: [""] resources: ["nodes/metrics", "nodes/stats"] verbs: ["get"] # Prefer this scoped access over granting nodes/proxy to a metrics-only agent.
Interview Tip
Explain the old `nodes/proxy` pattern, why it was risky, and how you would migrate Helm charts safely without breaking observability during a cluster upgrade.