Docker est une plateforme bien connue des développeurs. Si c’est une solution vous permettant de gagner en temps et en efficacité dans la gestion de votre infrastructure réseau, Docker peut aussi se révéler être une faille dans la sécurité de votre organisation. Utiliser Docker de manière sécurisée est possible, mais il faut le configurer de la bonne manière.
Dans cet article, nous allons explorer les mesures de sécurité les plus importantes lors de la configuration de votre environnement Docker.
Si vous êtes intéressé par la protection de votre infrastructure Docker, nous vous conseillons notre article sur comment sécuriser Docker pour son environnement de production.
Vous souhaitez devenir complètement opérationnels dans vos tâches de déploiement d’applications ? Notre formation Docker vous donnera une maitrise complète de l’outil et vous permettra de créer et de déployer des applications web.
l’équipe Ambient IT
Docker vs Docker Image
Pour bien comprendre la sécurité dans Docker il faut d’abord comprendre la différence entre Docker, qui exécute les images dans des conteneurs et les images en elles-mêmes.
Vous créez un conteneur à partir d’une image Docker. Une image Docker est une structure en couches dans laquelle vous définissez le processus qui doit être exécuté et les fichiers nécessaires à son exécution. Par exemple, si vous êtes un développeur Jakarta EE, il peut s’agir de l’installation du serveur Jakarta EE et de votre application.
Docker Hub est un référentiel dans lequel vous pouvez stocker et partager vos images Docker. Vous pouvez utiliser ces images pour créer un conteneur directement à partir d’elles, ou vous pouvez étendre ces images, les adapter à vos besoins et les utiliser à la place. La façon dont vous personnalisez votre image, en choisissant les binaires à inclure et leurs permissions, a un impact sur la sécurité de votre application.
Vous avez ensuite le programme qui dirige votre conteneur. Celui-ci dispose d’un daemon (un processus en arrière-plan qui n’est pas sous le contrôle direct de l’utilisateur) qui héberge les images, les conteneurs, les réseaux et les volumes de stockage. Il peut s’agir de Docker Engine ou d’une autre solution et est responsable de l’exécution de votre processus de manière isolée. La manière dont vous exécutez vos conteneurs a un impact sur la sécurité.
Sécuriser les images
Les images Docker que vous construisez n’offrent pas nécessairement une sécurité optimale dès le départ même si elles sont conformes aux règles de la spécification de l’Open Container Initiative (OCI).
Le principal problème lié à l’exécution d’un processus dans un conteneur est que lorsque l’application est piratée, l’attaquant peut accéder à l’hôte sous-jacent, ce qui représente un risque important pour de nombreux systèmes.
Pour palier à ce problème, assurez-vous que votre application ou votre processus dans le conteneur ne s’exécute jamais en tant qu’utilisateur root. Le processus root dispose de beaucoup plus d’autorisations et peut donc accéder à davantage de ressources de bas niveau. Dans votre script de conteneur, vous devez toujours avoir l’indication de l’utilisateur qui exécute le processus principal.
Idéalement, tous les binaires de votre processus et de votre application devraient appartenir à root mais n’avoir que des permissions de lecture et d’exécution de la part de l’utilisateur qui exécute votre processus. En cas d’intrusion, les conséquences sont alors bien moins graves. Cela s’appelle le principe du moindre privilège.
N’incluez donc dans vos images que les binaires absolument nécessaires. Moins il y a de binaires et d’exécutables présents, moins ils peuvent contribuer à des vulnérabilités potentielles en matière de sécurité.
Sécuriser les conteneurs
La façon dont vous exécutez les images et le logiciel avec lequel vous les exécutez peuvent également conduire à des vulnérabilités en termes de sécurité.
Comme pour les images, assurez-vous que les conteneurs ne possèdent pas d’accès privilégiés. Ils doivent fonctionner dans un bac à sable afin d’être isolés de l’hôte et d’autres conteneurs. Le statut privilégié supprime le bac à sable et ne devrait donc jamais être utilisé. Évitez par ailleurs de définir l’option –net=host car elle peut également affecter le bac à sable. Cela permet au conteneur d’ouvrir des ports plus faibles comme les processus root, ce qui peut affecter l’isolation.
Lorsque vous utilisez l’option réseau hôte lorsque vous exécutez le conteneur, il n’y a pas de mappage de port en vigueur et pas d’isolation pour le réseau hôte. Le conteneur utilise les mêmes ressources réseau que l’hôte. Les ports situés dans cette plage inférieure sont considérés comme des ports connus et ne sont généralement connectés que par des processus de super-utilisateurs.
Le processus de conteneur a accès à l’ensemble de la pile réseau et peut effectuer un balayage des autres ports. Ils ne sont généralement pas accessibles depuis le monde extérieur, mais peuvent être interrogés depuis le processus de conteneur puisqu’il utilise le réseau de l’hôte.
Aujourd’hui, les runtimes containerd et CRI-O peuvent également être utilisés pour exécuter des conteneurs basés sur les images Docker. L’implémentation omet plusieurs binaires et processus afin qu’ils soient plus légers, plus rapides et plus sûrs.
Les images et les conteneurs docker étant utilisés dans de nombreux cas de figure, en optimiser la sécurité nécessitera forcément un ajustement spécifique, mais en gardant en tête la règle du moindre privilège, vous devriez pouvoir garder une ligne directrice efficace.
