Le technologie des conteneurs est en plein expansion ces jours-ci. Parmi les plus connus, il y a Docker qui est à la mode dans la mouvance DevOps, et qui permet de gains de productivité et d’agilité incontestables. Toutefois, la technologie n’est pas forcément mature pour les grosses entreprises et l’industrialisation à grande échelle, en termes de stabilité et de sécurité. Certains éditeurs comme aquasec proposent des solutions pour aider à la sécurisation de ce type d’architecture.
Fondements de l’architecture Docker
Docker est un système de conteneurs, qui permet de faire tourner sur un même OS plusieurs applications en parallèle et de façon relativement isolée.
Les conteneurs Docker s’appuient sur l’OS et la virtualisation (l’isolation) ne concerne que le système de fichiers, les configurations et les zones d’état du système (comme la base de registres sous Windows par exemple)1. Notez bien : il n’y a pas d’isolation au niveau de la mémoire de travail (RAM).
Si cela représente d’indéniables avantages sur l’urbanisation et l’optimisation des ressources, cela implique que sur une machine donnée, tous les conteneurs doivent être basés sur le même kernel. Ainsi, si on peut faire tourner différents Linux sur une machine hôte Linux, il est impossible de faire tourner un conteneur Windows sur un hôte Linux, et réciproquement : in fine, le conteneur appellera toujours le noyau de l’hôte.
Un exemple de solution : Aqua
Leur approche repose sur un outil, Aqua, qui met l’accent sur 5 axes2 permettant d’inclure la sécurité dans le cycle de vie des DevOps :
- Gestion des vulnérabilités dans les images (des containers) ;
- Réduction de la surface d’attaque du container ;
- Renforcement du Contrôle d’Accès Utilisateur ;
- Durcissement de la machine hôte ;
- Automatisation de l’ensemble du process.
Gestion des vulnérabilités
Comme toute architecture fortement automatisée se basant sur des modèles, la sécurisation des modèles servant de base aux équipes de développement est une nécessité incontournable. Cependant, avec Docker, le rythme de modification des images de base augmente considérablement, ce qui va demander une validation quasi continue des images, et donc l’appréciation continue du niveau de sécurité des images utilisées.
Réduction de la surface d’attaque
Cette approche est classique pour tout environnement informatique, mais la sécurisation de conteneur est largement moins mature que celle de systèmes Linux, par exemple.
De plus, la communication entre conteneurs doit faire aussi l’objet de toutes les attentions : il est impératif de minimiser les communications entre conteneurs, en les rationalisant (pas d’ouverture de ports incontrôlés ni de droits trop ouverts sur l’OS), ce qui relève le plus souvent d’une démarche des développeurs et architectes.
Renforcement du contrôle d’accès des utilisateurs
Les premières versions de Docker imposaient l’utilisation du niveau root pour fonctionner, sans alternative possible. Cela ne pouvait pas perdurer si Docker voulait passer les portes des entreprises…
Les versions récentes sont beaucoup plus adaptées et permettent de gérer plus finement les droits, avec tous les gains associés en terme de ségrégation des rôles et de traçabilité. Il est incontournable de gérer alors ces droits de façon centralisée.
Durcissement de la machine hôte
Il s’agit principalement de s’assurer de l’isolation effective des conteneurs, ce qui est réalisé au niveau de l’OS. Or il faut que cette étape soit outillée et vérifiable, car comme plusieurs conteneurs peuvent s’exécuter sur le même OS, toute erreur de configuration peut conduire à des débordements !
Automatisation
L’automatisation est la raison d’être du DevOps, permettant l’agilité et la souplesse. L’automatisation de l’ensemble des processus doit inclure la sécurité, laquelle doit donc elle aussi être outillée et automatisée, afin que les DevOps et que les professionnels de la sécurité y trouvent leur compte.
Au niveau de Docker
Du fait que Docker s’appuie sur le système lui-même, les risques de débordement de ressources d’un conteneur à l’autre sont présents. Docker en a bien conscience, et ajoute des briques partout où c’est possible, mais le choix de la technologie LXC de Linux puis libcontainer3 laissera toujours planer le risque de lecture et/ou d’écriture par un conteneur cannibale (concurrent)4. Même avec des environnements de virtualisation ultra-rodés côté sécurité, le risque d’évasion de machine virtuelle est à considérer ; alors avec les conteneurs de type Docker, dont l’isolation est moins forte, ce risque est donc important et à prendre en compte lors que l’utilisation de ce type de technologie.
Les risques
Image compromise
Le premier risque est d’utiliser une image contenant des composantes malveillantes. Avec l’explosion du minage sauvage de cryptomonnaies depuis 2017, toutes les techniques sont bonnes pour faire de l’argent, et incorporer un logiciel de minage dans des images couramment utilisées peut se révéler très lucratif5 pour les petits malins.