Sécurisation des endpoints Kubelet : l'autorisation fine passe en GA

Kubernetes v1.36 marque une étape clé en matière de sécurité avec le passage en disponibilité générale (GA) de l'autorisation à granularité fine de l'API Kubelet (KubeletFineGrainedAuthz). Pendant des années, les équipes plateforme et les architectes d'infrastructure ont composé avec un compromis insatisfaisant : pour collecter les métriques système essentielles, les statistiques de conteneurs et les spécifications matérielles, les démons d'observabilité devaient disposer de la permission ClusterRole nodes/proxy, excessivement permissive. Cette exigence historique accordait aux agents tiers et aux pipelines de télémétrie internes des capacités de proxy globales sur les endpoints HTTPS du Kubelet des nœuds workers.

En activant par défaut et de façon définitive KubeletFineGrainedAuthz dans Kubernetes v1.36, le projet rend officiellement obsolète ce schéma à haut risque. Les responsables ingénierie, CTO et CISO peuvent désormais imposer un principe de moindre privilège rigoureux sur l'ensemble des Kubelets des nœuds workers. Cette fonctionnalité décompose l'accès proxy monolithique en liaisons verbe-chemin RBAC distinctes au niveau des sous-ressources. Par conséquent, les outils de télémétrie ne requièrent plus de permissions susceptibles d'être détournées pour lire des flux de logs, s'attacher à des conteneurs en cours d'exécution ou établir des sessions proxy WebSocket interactives directement sur les hôtes du cluster.

Impact métier et opérationnel

La justification stratégique de l'adoption d'une autorisation Kubelet à granularité fine repose sur la réduction du rayon d'impact (blast radius) et le respect des exigences réglementaires. Historiquement, un attaquant compromettant un agent de supervision doté des droits nodes/proxy pouvait exploiter le mécanisme de proxy de l'API server pour adresser des requêtes arbitraires directement aux Kubelets des nœuds workers. Ce vecteur d'attaque permettait l'exécution de commandes arbitraires au sein des pods, la traversée du système de fichiers de l'hôte et la prise de contrôle du nœud, en contournant les pare-feux réseau traditionnels et les normes de sécurité des pods.

Du point de vue de la gestion des risques, l'élimination de l'octroi obligatoire de nodes/proxy résout une réserve d'audit majeure pour les organisations soumises aux cadres SOC 2 Type II, ISO 27001, PCI-DSS ou FedRAMP. Les normes de conformité exigent explicitement un contrôle d'accès strict basé sur le moindre privilège pour les agents de télémétrie et d'audit. En restreignant les démons d'observabilité aux seules sous-ressources comme /metrics ou /stats, les équipes de sécurité d'entreprise peuvent faire la preuve d'une séparation stricte des responsabilités opérationnelles.

En outre, cette évolution réduit les frictions opérationnelles entre les équipes SecOps et SRE (Site Reliability Engineering). Les ingénieurs plateforme n'ont plus besoin de solliciter des dérogations de sécurité à haut risque pour déployer des piles de supervision standards comme Prometheus, Datadog ou OpenTelemetry Collector. Il en résulte un rythme de déploiement accéléré des services plateforme associé à un durcissement significatif de la posture de sécurité au runtime.

Schéma d'architecture et ingénierie

Sur le plan architectural, l'API Kubelet expose plusieurs endpoints HTTPS sur le port 10250, notamment /metrics, /metrics/cadvisor, /stats, /spec, /exec, /attach et /logs. Avant l'introduction de l'autorisation fine, les règles RBAC ne pouvaient pas faire de distinction granulaire entre une requête de lecture inoffensive vers /metrics et une requête interactive vers /exec.

Lorsque KubeletFineGrainedAuthz est actif en v1.36, le Kubelet délègue les décisions d'autorisation à l'API server Kubernetes au moyen de requêtes SubjectAccessReview incluant le chemin détaillé de la requête et les sous-ressources visées. Au lieu d'accorder des privilèges proxy globaux, les équipes plateforme créent désormais des objets ClusterRole ciblés, liés à des sous-ressources Kubelet spécifiques.

Considérons la transition opérationnelle. Sous l'ancien modèle, un scraper Prometheus nécessitait la configuration non sécurisée suivante :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-kubelet-legacy
rules:
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get", "list", "watch"]

Sous l'implémentation GA de la v1.36, ce ClusterRole est restructuré afin d'isoler précisément les chemins de sous-ressources :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-kubelet-v136
rules:
- apiGroups: [""]
  resources:
  - "nodes/metrics"
  - "nodes/stats"
  - "nodes/spec"
  verbs: ["get"]

Lorsqu'un pod d'observabilité émet une requête HTTP vers https://<node-ip>:10250/metrics, le Kubelet vérifie le certificat client ou le jeton porteur via l'authentification Webhook et exécute un SubjectAccessReview auprès de l'API server. L'API server évalue si le ServiceAccount détient les permissions get explicites sur nodes/metrics. En cas d'échec de l'autorisation, le Kubelet répond par un HTTP 403 Forbidden, isolant ainsi les endpoints /exec et /attach de toute invocation non autorisée.

Ce que cela change en pratique

• Auditer immédiatement les ClusterRoles existants : Inspecter l'ensemble des ServiceAccounts et ClusterRoles à travers les workloads, charts Helm et daemonsets afin d'identifier les références obsolètes à nodes/proxy.
• Refondre les manifestes de supervision : Mettre à jour les manifestes d'OpenTelemetry, Prometheus, Fluentbit et des agents de sécurité tiers pour demander des règles RBAC spécifiques aux sous-ressources (nodes/metrics, nodes/stats, nodes/spec).
• Éliminer les vecteurs d'escalade latérale : S'assurer que les comptes de service associés aux démons de supervision ne puissent pas être exploités pour exécuter des commandes à distance ou ouvrir des tunnels proxy WebSocket vers les nœuds workers du cluster.
• Mettre à jour les outils de contrôle de politique CI/CD : Intégrer des politiques OPA/Gatekeeper ou Kyverno qui détectent ou bloquent les ClusterRoles accordant la permission nodes/proxy dans les nouveaux déploiements.
• Vérifier la latence d'autorisation des Webhooks : Surveiller les métriques de performance de l'API server pour garantir que les évaluations SubjectAccessReview via Webhook entre le Kubelet et l'API server n'introduisent pas de délais d'expiration (timeouts) de collecte lors des pics de métriques.

L'approche d'Ali Run AIOps

Chez Ali Run AIOps, nous intégrons les principes du secure-by-design au cœur des architectures cloud-native, des migrations Kubernetes d'entreprise et des workflows SRE automatisés. Notre pratique d'ingénierie audite de façon systématique les topologies RBAC des clusters, identifiant les comptes de service sur-privilégiés et remplaçant les octrois de proxy monolithiques par des politiques de sous-ressources granulaires adaptées aux environnements Kubernetes modernes.

À travers nos services de conseil spécialisés et nos intégrations de plateforme AIOps, nous garantissons que les pipelines de télémétrie, les agents de sécurité et la supervision d'infrastructure fonctionnent selon des modèles stricts de moindre privilège. En combinant la détection automatisée des dérives RBAC et l'application continue de la conformité, Ali Run AIOps permet aux directions de l'ingénierie de préserver une visibilité complète sur leurs clusters tout en respectant des standards Zero Trust rigoureux.

Sources

• Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA
• Platform Engineering Monthly — April 2026