Kubernetes v1.33 corrige la réutilisation des images privées entre les pods

Dans un article publié sur le blog Kubernetes en mai 2025, les mainteneurs Ben Petersen et Stanislav Láznička ont décrit un ajustement de sécurité critique dans Kubernetes v1.33. Cette mise à jour résout un problème vieux d'une décennie où des pods pouvaient accéder par inadvertance à des images de conteneurs privées téléchargées par d'autres pods sur le même nœud, sans autorisation appropriée.

Ce qui s'est passé

Depuis plus de dix ans, les utilisateurs de Kubernetes sont confrontés à une faille de sécurité subtile mais significative liée au paramètre imagePullPolicy: IfNotPresent. Cette politique est conçue pour optimiser les performances en utilisant une image mise en cache localement si elle existe, plutôt que de la télécharger depuis le registre à chaque fois. Cependant, cette optimisation ignorait auparavant les limites d'authentification entre différents pods planifiés sur le même nœud.

Le problème central survenait lorsque le Pod A, autorisé avec des identifiants spécifiques via un imagePullSecret, téléchargeait une image privée sur un nœud. Si le Pod B, situé dans un namespace différent et ne disposant d'aucun identifiant valide pour ce dépôt privé, était ensuite planifié sur le même nœud avec la politique IfNotPresent, le Kubelet lui permettait d'utiliser l'image mise en cache. Le Pod B n'avait jamais été autorisé à télécharger l'image, mais il y accédait simplement parce que les couches binaires étaient déjà présentes sur le disque. Ce comportement violait le principe du moindre privilège et créait un risque potentiel pour la sécurité de la chaîne d'approvisionnement au sein des clusters.

Avec la sortie de Kubernetes v1.33, SIG Auth et SIG Node ont introduit une correction pour imposer la vérification des identifiants même lorsque les images sont mises en cache. Le nouveau comportement garantit qu'un pod ne peut utiliser une image privée présente localement que s'il fournit des identifiants correspondant à ceux utilisés lors du téléchargement initial. Cette modification ferme la brèche tout en maintenant les avantages en termes de performance de la mise en cache locale pour les charges de travail autorisées.

Comment cela fonctionne

La solution repose sur des caches persistants basés sur fichiers, maintenus par le Kubelet sur chaque nœud. Lorsqu'un pod demande une image qui n'est pas actuellement sur le nœud, le Kubelet enregistre l'intention de la télécharger. Il extrait ensuite les identifiants du Secret Kubernetes référencé et effectue le téléchargement depuis le registre privé. En cas de succès, le Kubelet stocke un enregistrement de cet événement, incluant un hachage des identifiants utilisés et l'identifiant du Secret source.

Lorsqu'un pod ultérieur demande la même image, le Kubelet vérifie son cache local. Au lieu de servir aveuglément l'image mise en cache, il compare les identifiants fournis par le nouveau pod aux enregistrements stockés. Si le hachage des identifiants ou le Secret source correspond à un téléchargement réussi précédent, le pod reçoit l'accès à l'image mise en cache sans re-télécharger les données. S'il n'y a pas de correspondance, le Kubelet tente de télécharger l'image depuis le registre distant en utilisant les nouveaux identifiants, déclenchant ainsi le flux d'autorisation standard. Ce mécanisme garantit que seuls les pods disposant d'identifiants valides et correspondants peuvent réutiliser les images privées mises en cache.

Détails clés

• La correction traite le problème 18787, une réserve de sécurité présente dans Kubernetes depuis plus de dix ans.
• La fonctionnalité est disponible en version alpha dans Kubernetes v1.33.
• Les utilisateurs doivent activer la porte de fonctionnalité KubeletEnsureSecretPulledImages sur leurs Kubelets pour activer le nouveau comportement.
• Les pods utilisant le même identifiant ou le même Secret source n'ont pas besoin de se ré-authentifier, préservant ainsi les performances.
• La politique imagePullPolicy: Never exige désormais également une vérification des identifiants pour les images privées déjà présentes sur le nœud.
• Les plans futurs incluent l'intégration avec les jetons de compte de service projetés (Projected service account tokens) et l'ajout de la prise en charge de l'expiration des identifiants.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes de plateforme, cette modification renforce l'isolation des clusters sans nécessiter de changements opérationnels drastiques. Auparavant, de nombreuses organisations imposaient imagePullPolicy: Always comme solution de contournement pour garantir que chaque pod effectue une vérification d'authentification auprès du registre. Bien que sécurisée, cette approche plaçait le registre d'images sur le chemin critique pour chaque démarrage, montée en charge ou redémarrage de pod, augmentant la latence et la dépendance aux services externes. Le nouveau mécanisme de vérification permet aux équipes d'utiliser IfNotPresent en toute sécurité, réduisant la charge du registre et améliorant les temps de démarrage tout en maintenant des contrôles de sécurité stricts.

Cette mise à jour simplifie également la gestion des clusters multi-locataires. Dans les environnements où plusieurs équipes partagent des nœuds, le risque qu'une équipe accède accidentellement aux images privées d'une autre équipe est désormais atténué au niveau du Kubelet. Les ingénieurs de plateforme peuvent compter sur l'infrastructure pour appliquer les politiques d'accès plutôt que de dépendre uniquement des politiques réseau ou des contrôleurs d'admission pour empêcher l'utilisation non autorisée d'images. Ce changement aligne le comportement de Kubernetes plus étroitement sur les attentes des utilisateurs en matière de sécurité et d'isolation.

Ce que vous pouvez faire

• Mettez à niveau vos clusters de test vers Kubernetes v1.33 pour évaluer la nouvelle fonctionnalité.
• Activez la porte de fonctionnalité KubeletEnsureSecretPulledImages dans votre configuration Kubelet.
• Examinez vos paramètres actuels imagePullPolicy et envisagez de passer de Always à IfNotPresent là où c'est approprié pour améliorer les performances.
• Assurez-vous que tous les pods accédant à des images privées référencent correctement les imagePullSecrets nécessaires.
• Surveillez les journaux du Kubelet pour détecter tout échec d'authentification lors du déploiement initial afin d'identifier les pods mal configurés.
• Consultez KEP-2535 pour obtenir les spécifications techniques détaillées et les éléments de feuille de route future concernant cette fonctionnalité.