Docker et la sécurité

L’explication sur le fonctionnement Docker nous amène à réfléchir à la sécurité des différentes briques de l’application. Une mauvaise configuration du système hôte, du daemon docker et aussi des containers eux-mêmes peut conduire à la compromission générale qui se joue principalement autour :

• Du noyau du système hôte partagé avec le daemon docker et les containers. Si un attaquant vient à compromettre le noyau mutualisé entre les containers, l’impact sur le système sera alors général et touchera alors l’ensemble des containers (type Kernel Panic par exemple).
• De l’élévation de privilège : Un utilisateur root dans un container peut devenir root sur le système hôte et ainsi se voir attribuer les droits d’accès à l’ensemble des containers.
• De la compromission des images Docker ou contenu obsolète contenant des vulnérabilités. Malgré une vérification des Hash des images du Docker Hub, celles-ci peuvent tout de même contenir du code malveillant.
• D’une utilisation abusive de l’API qui permet de passer les commandes d’administration au daemon Docker. Sans une authentification ou un contrôle d’accès, un utilisateur normal ayant le contrôle de l’API peut facilement devenir root du serveur hôte ou maîtriser l’ensemble des containers.
• Des dénis de service (DoS) : l’utilisation excessive des ressources du système hôte par un container peut amener à une interruption de service de l’ensemble des autres containers hébergés sur le même système hôte.

Ces risques sont fortement diminués en respectant une liste de bonnes pratiques de configuration et en maintenant le système hôte et les paquets du système et des conteneurs à jour.

Plus ou moins complexes à mettre en place et assurant des niveaux de sécurité différents, les axes de sécurisation d’une infrastructure « Dockerisée » sont les suivants :

• Durcir les serveurs hôtes hébergeant le daeon Docker et les containers.
• Les images doivent être à jour et ne posséder que le strict minimum. Éviter le stockage de secrets au sein d’une image, la présence de ssh ou d’outils d’administration. Moins le container possède d’outils et de paquets, plus la tâche de compromission sera difficile.
• Construire un réseau cloisonné dont chaque composant Docker se voit attribuer un segment particulier (communication hôte-hôte, containers, administration, servitudes, etc.). Définir des politiques sécurisées de communication et d’administration au sein l’infrastructure.
• Vérifier les sources de construction des images utilisées par les containers et assurer un suivi de leurs évolutions en appliquant une signature numérique interne.
• Un scan de vulnérabilité de l’image doit être implémenté avant la validation de celle-ci en tant qu’image de confiance.
• Limiter les appels système, les ressources d’un container et minimiser l’exécution des containers en mode privilégié. Le UserMapping du User NameSpace est vivement conseillé.
• Intégrer un mécanisme de contrôle d’accès et de gestion de rôle/profil des utilisateurs/administrateur de la solution (sécuriser l’API par un outil RBAC).
• Suivre les évolutions de configuration et centraliser les journaux d’événement.
• Surveiller le niveau de sécurité global régulièrement à l’aide d’audit et de scanneur réseau et applicatif. Cela permet d’identifier les vulnérabilités des serveurs hôtes et des applications hébergées dans des containers et de suivre leur correction.
• Ne pas exposer directement un container sur Internet, les mécaniques habituelles de protection doivent s’appliquer : Reverse Proxy, Firewall/ WAF, etc.

cf. https://www.lemagit.fr/tribune/Introduction-aux-risques-et-a-la-securisation-de-Docker-2e-partie