icetray - Fotolia

Actualites

Kubernetes : une vulnérabilité critique susceptible de retarder les mises à jour

Les entreprises qui paient pour le support de Kubernetes répondront différemment à la vulnérabilité critique de cette semaine que les petites équipes DevOps utilisant le code amont.

Beth Pariseau
par
Publié le: 05 déc. 2018

La vulnérabilité CVE-2018-1002105 est critique : elle permet à un attaquant d’élever ses privilèges via Kubernetes. Avec ce dernier comme norme de facto pour l'orchestration de conteneurs, la faille représente un risque potentiellement considérable pour l'ensemble de l'industrie informatique.

La communauté open source de Kubernetes a publié un correctif en amont pour la version 1.10 et les versions ultérieures et il est déjà appliqué aux services Kubernetes hébergés, tels que Google Kubernetes Engine et Red Hat OpenShift Online/Starter. Cependant, les utilisateurs de déploiements sur site ou des clusters Kubernetes hébergés dans le cloud devront déployer la rustine eux-mêmes.

Gary Chen, analyste chez IDC, souligne l’ampleur de l’incident : « il y a déjà eu des failles Kubernetes par le passé, mais c'est certainement la pire. C'est toujours le problème avec les systèmes de contrôle centralisés. Si quelqu'un en prend le contrôle, il peut avoir accès à tout le reste ».

Darren Shepherd, co-fondateur et architecte chez Rancher, basé à Cupertino, a signalé la vulnérabilité à l'équipe de sécurité Kubernetes la semaine dernière. La faille a été corrigée cette semaine et a été rendue publique en même temps que le correctif après un embargo d'une semaine.

Kubernetes 1.10 est sorti fin mars 2018, donc la vulnérabilité est restée sans correction pendant environ neuf mois. Les contributeurs de Kubernetes, tels que Red Hat, estiment que c'est une fenêtre courte comparée à d'autres vulnérabilités critiques comme Heartbleed, ou encore Spectre et Meltdown, qui sont restées exploitables durant des années.

Pour Chris Robinson, responsable de la sécurité des produits chez Red Hat, si « il est toujours terrible de trouver un problème grave », l'équipe de Kubernetes « l'a pris très au sérieux et a réagi rapidement ». Et d’ajouter que le phénomène n’est pas totalement isolé : « c'est une tendance que nous avons observée avec les embargos CVE [Common Vulnerabilities and Exposures] dans l’open source, ces cinq dernières années, en général. En moyenne, ils sont passés de 14 jours à environ 10 ».

Une vulnérabilité qui expose les disparités du marché

Mais pour certains experts, seules les grandes équipes informatiques disposant d'implémentations Kubernetes packagées peuvent suivre le rythme trimestriel de mises à jour pour l'outil d'orchestration et cette vulnérabilité Kubernetes constitue un obstacle supplémentaire aux mises à jour rapides, au-delà de la version 1.8.

Rick Moss, ingénieur d'exploitation des infrastructures chez MailChannels, un fournisseur de services de messagerie de Vancouver, relève ainsi que « Kubernetes est peut-être la norme, mais en son sein, il existe de multiples normes à choisir entre les versions 1.8 et 1.12. De nombreuses entreprises passent lentement aux versions 1.10+, en raison des exigences relatives à TLS et du contrôle des espaces de nommage, parce qu’elles rendent les cycles de développement et de déploiement plus complexes ».

Et d’ajouter que de nombreuses entreprises gèlent les mises à jour et les déploiements en production entre début décembre et mi-janvier, ce qui rend la nécessité de corriger cette vulnérabilité particulièrement inopportune : « si vous voulez gâcher Noël, dévoilez un CVE important début décembre. Mais, si vous avez besoin de déployer ce correctif, ne pas le faire pourrait également changer radicalement vos projets pour Noël ».

Les entreprises dotées de grandes équipes informatiques dédiées au support de l'infrastructure et qui disposent des ressources financières nécessaires à l’achat de packages Kubernetes supportés commercialement, seront mieux loties que les équipes petites DevOps qui ne sont peut-être pas bien formées à la sécurité de l'infrastructure. Ce qui pourrait bien constituer un argument en faveur des distributions packagées par rapport au code amont, mais la réalité, pour Rick Moss, est que le coût est roi dans le monde des logiciels libres.

Alors selon lui, les entreprises qui n'ont pas les ressources nécessaires pour répondre à ce type de vulnérabilité retarderont plutôt les mises à jour, voire ignoreront simplement le problème : « ce n'est pas comme si nous n’avions jamais vu de vulnérabilités de ce genre par le passé, mais il s'agit d'un nouveau problème basé sur la religion des DevOps et des petites équipes. La vérité est que les déploiements d'infrastructure à grande échelle ont besoin d'une équipe dédiée pour surveiller et maintenir, et les petites équipes peuvent se trouver bloquées ».

Toutefois, certains utilisateurs du code amont estiment qu'ils n'auront pas de problème pour appliquer le correctif. Mais l’idée d’autres vulnérabilités Kubernetes a affecté leur modèle d'exploitation. Ainsi, Adam Brown, co-fondateur de Mux Inc, une startup de streaming vidéo à San Francisco qui dessert des géants des médias tels que CBS et PBS, indique avoir « des clusters spécifiques aux applications, et ceux-ci ne sont accessibles que par les utilisateurs qui ont un accès administrateur complet. Nous nous attendons à ce que cela change à l'avenir et des bugs comme celui-ci sont assez inquiétants. Mais, pour l'instant, [la vulnérabilité] ne semble pas exploitable dans nos grappes ». 

Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)