Quand on sécurise Kubernetes, on pense souvent aux images, aux conteneurs, aux droits RBAC ou aux secrets. Mais une autre couche mérite la même attention : le stockage et les composants privilégiés qui le relient au cluster.
Ce que montre l’alerte Dell CSM
Dell a publié le 1er octobre 2026 l’avis de sécurité DSA-2026-448 concernant plusieurs vulnérabilités dans Container Storage Modules (CSM). Deux d’entre elles, CVE-2026-63688 et CVE-2026-63692, obtiennent un score CVSS de 10/10.
Selon Dell, CVE-2026-63688 pouvait permettre à un attaquant distant non authentifié d’accéder aux identifiants administrateur des systèmes de stockage enregistrés. CVE-2026-63692 pouvait permettre une élévation de privilèges jusqu’au niveau administrateur du service d’autorisation.
Le point important
Une faiblesse dans une extension de stockage peut devenir une faiblesse du cluster lui-même, voire de l’infrastructure qui se trouve derrière.
Pourquoi le stockage est si sensible dans Kubernetes
Kubernetes s’appuie généralement sur le standard CSI — Container Storage Interface pour connecter les workloads à des volumes persistants. Les pilotes et modules CSI peuvent créer, attacher, monter et supprimer des volumes, gérer des snapshots et manipuler des identifiants d’accès.
Ces composants disposent donc naturellement de permissions importantes. Leur compromission peut avoir un impact bien supérieur à celle d’une application confinée dans un pod.
La surface d’attaque réelle est plus large que Kubernetes
Un cluster moderne dépend souvent de nombreux composants qui ne font pas partie du cœur de Kubernetes mais qui disposent de droits élevés :
- pilotes CSI et systèmes de stockage ;
- operators et controllers ;
- Ingress controllers ;
- agents de supervision et de sécurité ;
- outils de sauvegarde ;
- gestionnaires de certificats et de secrets ;
- outils GitOps et runners CI/CD.
La question « Kubernetes est-il à jour ? » ne suffit donc pas. Il faut aussi demander : quels composants privilégiés gravitent autour du cluster, et sont-ils tous identifiés, maintenus et surveillés ?
D’autres vulnérabilités renforcent le constat
L’avis Dell inclut également d’autres vulnérabilités critiques. CVE-2026-67269, notée 9,9, pouvait permettre à un utilisateur faiblement privilégié d’obtenir un accès root sur des nœuds via CSM Operator. CVE-2026-67273 pouvait notamment exposer des Secrets Kubernetes à l’échelle du cluster et permettre la modification de ressources RBAC.
Le stockage n’est donc pas un composant périphérique : il peut devenir un chemin vers les nœuds, les secrets et les autorisations centrales du cluster.
Trois vérifications à intégrer
1. Inventorier les composants privilégiés
Operators, DaemonSets, pilotes CSI, agents de supervision et services capables d’interagir avec l’API Kubernetes doivent être identifiés explicitement. Un composant oublié finit souvent aussi par être oublié lors des mises à jour.
2. Vérifier les permissions
Contrôler régulièrement les ClusterRoles, ClusterRoleBindings, ServiceAccounts, accès aux Secrets, pods privilégiés et montages depuis l’hôte permet de repérer des droits devenus excessifs.
3. Suivre les avis de sécurité des dépendances
Mettre Kubernetes à jour ne met pas automatiquement à jour ses drivers, operators et outils tiers. Ces composants doivent être traités comme des dépendances de sécurité à part entière.
Que doivent faire les utilisateurs de Dell CSM ?
Dell recommande de mettre à niveau les installations concernées vers Container Storage Modules 1.18.0 ou une version ultérieure. L’avis n’indique pas de contournement pour les vulnérabilités principales.
- identifier la version CSM actuellement déployée ;
- appliquer la mise à jour recommandée ;
- vérifier l’exposition réseau des services CSM ;
- contrôler les secrets et identifiants liés au stockage ;
- examiner les permissions accordées aux composants CSM.
Ce que cela suggère pour TechAtelier
Pour une analyse de posture, il est utile de ne pas s’arrêter aux versions Kubernetes et aux workloads visibles. Les extensions installées, leur niveau de privilège, leur exposition et leur cycle de maintenance sont tout aussi importants.
Cette logique peut s’appliquer plus largement à toute infrastructure : la surface d’attaque réelle inclut les composants qui administrent, observent, sauvegardent ou connectent les systèmes principaux.
Ce qu’il faut retenir
Cette alerte Dell dépasse le seul cas de CSM. Dans Kubernetes, la sécurité du cluster dépend aussi de tout ce qu’on lui connecte.
Un pilote de stockage, un operator ou un agent de supervision peut disposer de privilèges supérieurs à ceux des applications qu’il accompagne. La chaîne à surveiller devient donc :
applications → conteneurs → Kubernetes → extensions → stockage → infrastructure.
Sources
Publié le 4 octobre 2026. Les versions et recommandations correspondent à l’avis Dell disponible à cette date.