Qui a encore besoin de machines virtuelles aujourd'hui ? – le blog de sécurité informatique d'AVANTEC

À propos de cette offre

Vous avez sûrement déjà vu l'image du titre sous cette forme ou une forme similaire. On la retrouve dans environ 90 % des articles traitant des plateformes de conteneurs. Bien que ce type d'image soit déjà « surutilisé », je souhaite tout de même l'utiliser ici. Cet article porte sur les plateformes conteneurisées, plus précisément sur Docker, Kubernetes et Openshift. Quand j'entends le terme « conteneur », je pense d'abord aux vieux blocs de fer rouillés et lourds transportés sur d'immenses navires à travers les océans. Mais à part le terme, ces conteneurs n'ont pas grand-chose à voir avec la technologie des conteneurs en informatique aujourd'hui. Plusieurs conteneurs peuvent tenir sur un navire, mais en quoi cela diffère-t-il d'une autre plateforme de virtualisation comme VMWare ESX ? Là aussi, plusieurs machines virtuelles peuvent tourner sur un ESX, alors pourquoi des conteneurs ? D'où vient le battage médiatique ? Le mot « Agile » (prononcé : áʤɑjl) vous est probablement familier. Il désigne plusieurs méthodes de développement logiciel agiles, toutes relativement récentes. L'article Wikipédia sur le développement logiciel agile remonte à 2005, mais ce n'est qu'après 2010, voire après 2015, que ce sujet est devenu vraiment connu dans les grandes entreprises suisses (banques, assurances, etc.) et a fait le tour avec la sortie de Docker. Cela a créé un engouement – « Ils l'ont, alors nous aussi on le veut ». Dès qu'une entreprise a commencé, beaucoup d'autres ont rapidement suivi. J'étais moi-même dans le secteur bancaire à cette époque et on ressentait clairement ce battage. Tout le monde voulait des conteneurs et être agile parce que les autres le faisaient. Tout le monde voulait être à la table des enfants cools. Ainsi, Docker, en tant que leader du marché, a rapidement trouvé sa place dans les entreprises. Chacun est libre d'avoir son opinion sur les méthodes agiles. Beaucoup en sont enthousiastes, mais j'ai aussi entendu pas mal de critiques : si on ne suit pas précisément les méthodes, le développement logiciel peut devenir chaotique, chacun faisant un peu ce qu'il veut, car « nous sommes agiles ». Mais être agile ne signifie pas développer le logiciel en freestyle. Les opinions négatives sont aussi dues au battage autour du terme « être agile ». Personnellement, je n'ai pas assez travaillé avec pour me permettre un jugement définitif. Évolution des conteneurs Il n'est pas surprenant que le concept de conteneurisation ait été développé sous Linux. Chez l'entreprise aux 6 lettres colorées, basée dans le soleil californien, beaucoup de choses ont été développées pour l'informatique. Il s'agit de Google. Google, avec tous ses services, a besoin d'une quantité importante de ressources. Autrefois, tout était virtualisé de manière classique comme on le connaît : hôte, machine virtuelle, puis un système d'exploitation avec l'application. Cela nécessite pour chaque application les ressources d'un système complet, car rarement plusieurs applications tournent sur un même système, rendant le partage des ressources difficile. Paul Menage et Rohit Seth de Google ont abordé ce problème et, sous le nom de projet « process containers », ont commencé en 2006 à développer la base actuelle des conteneurs sous Linux. Leur travail a donné naissance à une fonctionnalité du noyau Linux appelée Control Groups ou cgroups. Avec cgroups, on peut lier les ressources comme le CPU, la RAM ou l'I/O à des processus individuels ou des groupes de processus. Cela devait poser les bases de la révolution du cloud computing : la conteneurisation. Fonctionnement Les conteneurs sont une abstraction au niveau de l'application, regroupant le code et ses dépendances. Plusieurs conteneurs peuvent tourner sur la même machine et partager le noyau du système d'exploitation avec d'autres conteneurs, chacun s'exécutant comme un processus isolé dans son propre namespace. Comme les conteneurs n'ont pas un système d'exploitation complet, ils ont moins de surcharge et nécessitent moins d'espace que les machines virtuelles. L'idée de base du conteneur n'est pas nouvelle, certains se souviendront peut-être des anciennes machines Solaris ? Ces pièces robustes en aluminium ? Là aussi, on connaissait déjà les conteneurs et les nœuds, mais ce n'était pas aussi avancé qu'aujourd'hui. Contrairement aux machines virtuelles sur une plateforme hôte, Docker opère un niveau au-dessus. Il n'y a qu'un seul OS hôte, dont le noyau est utilisé par les applications dans les conteneurs. Cela rend le déploiement des conteneurs extrêmement rapide et simple. Conteneurs dans le développement logiciel Le développement logiciel bénéficie de l'efficacité du travail avec les conteneurs. Un conteneur est déployé en quelques secondes, peut être testé brièvement, puis supprimé. Ensuite, le code de l'application est ajusté, et le conteneur est redéployé et testé. Ainsi, une version est toujours disponible. Une fois qu'un conteneur a fonctionné de manière fiable avec tous les composants, il peut être conservé comme sauvegarde immuable. Ce conteneur peut toujours servir de base. Qu'en est-il de la sécurité ? La sécurité de la virtualisation de conteneurs la plus connue, Docker, est souvent critiquée. Mais c'est comme pour une installation classique : tout dépend de la sécurité du système hôte. Un exemple est SELinux, souvent désactivé car sa gestion est très lourde. Bien que la sécurité d'un environnement conteneur soit considérée comparable à celle d'une virtualisation classique, cela mérite d'être remis en question. Justement parce que Docker opère un niveau au-dessus, les ressources ne sont pas aussi strictement séparées. Par exemple, un « débordement de tampon » peut permettre d'accéder à des zones normalement interdites. Avec un hyperviseur classique, la virtualisation est un niveau plus bas, rendant ce type d'exploitation impossible. C'est pourquoi la devise est : l'isolation, lorsque plusieurs conteneurs tournent sur un hôte commun, dépend de la capacité du noyau à fournir une isolation multi-locataire entre les conteneurs et le système d'exploitation hôte sous-jacent. Cela inclut notamment les namespaces du noyau Linux, SELinux et d'autres fonctionnalités de sécurité de la distribution Linux choisie, ainsi que la sécurité de la distribution elle-même. En fin de compte, un conteneur ne peut être aussi sûr que le noyau de l'hôte sur lequel il tourne. Cela ne signifie pas que le conteneur est « toujours » aussi sûr que l'hôte. Chaque conteneur doit être patché en cas de vulnérabilité, sinon il reste vulnérable. Des failles comme Spectre ou Meltdown peuvent, dans le pire des cas, affecter tout le système. Ce qui m'inquiète le plus actuellement, c'est que nous n'avons qu'un seul noyau et que nous sommes séparés des autres systèmes uniquement par différents namespaces. Si le noyau a une faille, il est possible d'en sortir pour accéder au système hôte et exécuter du code dessus. Un risque existe aussi si le système hôte est mal configuré et – hypothétiquement – si l'API Docker est accessible publiquement. Qui ferait cela ?... Il y a eu un incident il y a deux ans... Exactement ! En 2017, un port ouvert pour l'API Docker a permis à un attaquant de déployer une image Docker contenant un mineur pour la cryptomonnaie Monero, exploitant la puissance CPU d'autres machines. Grâce à l'isolation des conteneurs, il n'était pas facile d'accéder au système hôte, donc cela s'est limité au minage de Monero. À part une facture d'électricité plus élevée, aucun dommage n'a été causé. Cela reste toutefois inquiétant. L'attaque est décrite en détail ici : https://kromtech.com/blog/security-center/cryptojacking-invades-cloud-how-modern-containerization-trend-is-exploited-by-attackers Orchestration des conteneurs avec Openshift Dès que plusieurs conteneurs s'accumulent dans un paysage système, ils doivent être gérés. Leur nombre peut rapidement atteindre trois chiffres, rendant la supervision difficile. Kubernetes est un projet open source adapté à cela. Openshift est le produit basé sur Kubernetes développé par RedHat pour gérer un environnement de conteneurs. Contrairement à Kubernetes, il offre déjà de nombreux composants complets comme l'intégration continue, la livraison continue, la sauvegarde et des fonctionnalités de sécurité. OpenShift a été conçu dès le départ pour l'entreprise et est donc plus restreint par défaut. Par exemple, il ne permet pas de déployer des conteneurs fonctionnant en root et ne tourne que sous RedHat/CentOS. Conclusion L'histoire des conteneurs est donc, selon l'activité d'une entreprise, déjà largement répandue. Là où RedHat est utilisé, un POC pour Docker & Openshift est au moins en cours. RedHat a lui-même ressenti la diffusion d'Openshift, les formations et certifications associées sont très fréquentées. Bien qu'il y ait eu un battage initial autour des conteneurs et Docker, et qu'on pouvait remplir une carte de bingo avec les mots-clés en réunion, je vois cette technologie comme une évolution positive. Le développement logiciel bénéficie énormément de l'agilité accrue et peut, en collaboration avec des méthodes comme SCRUM, augmenter significativement l'efficacité. Qu'en pensez-vous ? Faites-moi savoir ce que vous en pensez. « Docker est pratique et peut éviter beaucoup de travail inutile, mais le confort ne doit pas mener à des actions imprudentes. » – Tim Berghoff, évangéliste sécurité chez G DATA Liens Chez AVANTEC, nous nous occupons de la sécurité des conteneurs dans le cadre de la sécurité cloud : www.avantec.ch/themen/cloud-security/ L'article Qui a encore besoin de machines virtuelles aujourd'hui ? est initialement paru sur Tec-Bite.