Cet article explique pourquoi les SVIDs SPIFFE/SPIRE à courte durée de vie dépendent encore de l’intégrité des nœuds, ce qu’a montré un test de falsification cgroup en laboratoire et quelles mesures Kubernetes peuvent en limiter l’impact.
SPIFFE fournit aux services des documents d’identité cryptographiques à courte durée de vie, appelés SVIDs. Les charges de travail peuvent les utiliser pour établir des connexions TLS ou pour signer et vérifier des JWTs. La présentation officielle de SPIFFE définit ce modèle.
Où se prend la décision d’attribution d’identité
SPIRE procède à l’attestation des nœuds et des charges de travail avant de délivrer des SVIDs. Lors de l’attestation d’une charge de travail, l’agent SPIRE détermine les propriétés d’un processus à partir de sources locales, comme le noyau du système d’exploitation ou un kubelet situé sur le même nœud. Il compare ensuite ces propriétés aux conditions des sélecteurs définies dans une entrée d’enregistrement ; une correspondance détermine le SPIFFE ID attribué au processus. La documentation sur les concepts de SPIRE décrit ce mécanisme.
La portée du résultat obtenu en laboratoire
Dans ce modèle, la validité cryptographique d’un SVID et son attribution au processus prévu sont deux questions distinctes. Les recherches menées en laboratoire par Unit 42 ont montré qu’un attaquant disposant déjà d’un accès root sur un nœud Kubernetes pouvait falsifier les informations cgroup de Linux, tromper l’agent SPIRE et obtenir un SVID valide appartenant à une autre charge de travail sur le même nœud. Le déroulement technique est documenté dans les recherches de Unit 42.
Unit 42 indique explicitement n’avoir observé cette technique dans aucune attaque réelle. Ce résultat ne constitue donc pas une preuve d’exploitation active ; il décrit un risque post-exploitation qui apparaît une fois que l’accès root a rompu la confiance dans le nœud.
Un modèle de défense face aux risques liés aux nœuds
Pour planifier la défense, la compromission d’un nœud doit être traitée comme une compromission de toutes les identités de charges de travail rattachées à ce nœud. Les recommandations de Unit 42 comprennent la restriction des conteneurs privilégiés et de l’accès direct à l’hôte, ainsi qu’une moindre dépendance aux sélecteurs faibles ou faciles à falsifier. Le périmètre concerné est le nœud compromis, et non automatiquement l’ensemble du cluster.
Réduire les privilèges des pods et des nœuds
Le profil Restricted des Pod Security Standards de Kubernetes prévoit d’interdire les pods privilégiés, de bloquer l’élévation de privilèges et d’exécuter les conteneurs avec des utilisateurs autres que root. La liste de contrôle officielle de sécurité indique également que seccomp peut réduire la surface d’appels système du noyau Linux accessible depuis les conteneurs. Les détails figurent dans les Pod Security Standards et dans la liste de contrôle de sécurité de Kubernetes.
Considérer les sélecteurs comme une composante de la frontière de confiance
Les sélecteurs ne sont pas de simples critères de correspondance : ils déterminent quelles propriétés locales sont prises en compte dans la décision d’attestation. Un examen doit donc identifier les données du système d’exploitation ou du kubelet qui alimentent chaque condition, et déterminer si un accès root pourrait faciliter leur falsification. L’objectif est de s’appuyer sur des sélecteurs qui distinguent précisément les charges de travail, plutôt que sur des conditions trop larges ou peu robustes.
Séparer les niveaux de sensibilité et limiter les éléments d’authentification supplémentaires
Kubernetes recommande également de placer les charges de travail présentant des niveaux de sensibilité différents sur des nœuds distincts et de ne pas monter de jetons de compte de service dans les pods qui n’en ont pas besoin. Ces deux mesures sont décrites dans la liste de contrôle officielle de sécurité.
La répartition sur des nœuds distincts vise à rendre plus difficile un rebond direct vers des applications plus sensibles après une évasion de conteneur. Ne pas monter un jeton de compte de service inutile évite aussi qu’un élément d’authentification supplémentaire, distinct du SVID, soit présent dans le pod.
Une démarche pratique de vérification
Cette frontière de confiance peut se traduire par une courte série de vérifications qui examine à la fois la configuration et le placement des charges de travail :
Périmètre des identités : Quels SPIFFE ID relèvent du périmètre de chaque nœud, et quels niveaux de sensibilité coexistent sur ce nœud ?
Données d’attestation : Quelles données du système d’exploitation ou du kubelet alimentent les sélecteurs, et un accès root permettrait-il de les falsifier ?
Privilèges sur le nœud : Quels pods sont privilégiés, peuvent accéder à l’hôte, autorisent l’élévation de privilèges ou s’exécutent en tant que root ?
Éléments d’authentification supplémentaires : Quels pods reçoivent des jetons de compte de service alors qu’ils n’en ont pas besoin ?
La conclusion n’est pas que les SVIDs sont sans intérêt. Leurs garanties d’identité cryptographique doivent être évaluées conjointement avec l’intégrité du nœud où a lieu l’attestation. Un modèle résilient associe des identités de charges de travail à courte durée de vie, le durcissement des pods, des conditions de sélection précises, une répartition sur des nœuds distincts selon la sensibilité et la suppression des éléments d’authentification inutiles.
