OpsCanary
Back to daily brief
kubernetesPractitioner

Kubernetes v1.36: Mastering Fine-Grained Kubelet API Authorization

5 min read Kubernetes BlogApr 24, 2026
Share
PractitionerHands-on experience recommended

Fine-Grained Kubelet API Authorization exists to address the security risks associated with overly broad access to the kubelet's API. By enabling more precise access control, it helps you implement the principle of least privilege, which is crucial in production environments where security is paramount.

With KubeletFineGrainedAuthz, the kubelet performs an additional authorization check before defaulting to the broad nodes/proxy subresource. This means that several commonly used kubelet API paths are now mapped to their own dedicated subresources, such as /metrics/* for metrics and /stats/* for stats. When a request is made, the kubelet first sends a SubjectAccessReview for the specific subresource. If the check passes, the request is authorized; if it fails, it falls back to the coarse-grained nodes/proxy subresource for compatibility.

In practice, this means you should adjust your RBAC configurations to take advantage of this fine-grained control. Instead of granting broad permissions like nodes/proxy, you can specify permissions for individual resources like nodes/metrics and nodes/stats. This not only enhances security but also aligns with best practices in Kubernetes access management. Remember, this feature graduated to GA in v1.36, following its introduction in v1.32 as Alpha and v1.33 as Beta, so it's stable and ready for production use.

Key takeaways

  • Implement least-privilege access by using specific subresources like nodes/metrics and nodes/stats.
  • Utilize SubjectAccessReview for fine-grained authorization checks before falling back to broader permissions.
  • Transition from broad permissions in RBAC to more specific rules to enhance security.

Why it matters

This feature significantly reduces the risk of unauthorized access to sensitive kubelet API endpoints, which is critical for maintaining a secure Kubernetes environment in production.

Code examples

YAML
1# Old approach: overly broad
2apiVersion: rbac.authorization.k8s.io/v1
3kind: ClusterRole
4metadata:
5  name: monitoring-agent
6rules:
7- apiGroups:
8  - ""
9  resources:
10  - nodes/proxy
11  verbs:
12  - get
YAML
1# New approach: least privilege
2apiVersion: rbac.authorization.k8s.io/v1
3kind: ClusterRole
4metadata:
5  name: monitoring-agent
6rules:
7- apiGroups:
8  - ""
9  resources:
10  - nodes/metrics
11  - nodes/stats
12  verbs:
13  - get
Bash
1# Get the token
2TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
3# Query the kubelet metrics and filter for the feature gate
4curl -sk \
5  --header "Authorization: Bearer $TOKEN" \
6  https://$NODE_IP:10250/metrics \
7  | grep kubernetes_feature_enabled \
8  | grep KubeletFineGrainedAuthz

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.