Pourquoi remplacer Docker ? Quelles sont les limites de cet outil ?

Publié le

Cet article fait partie d'une série dont le but est de montrer comment remplacer Docker par plusieurs autres outils : podman, buildah, cri-o. Dans ce premier article, je vous propose de voir quelles sont les raisons qui ont poussé à la création d'autres outils pour gérer les containers.

D'après la documentation officielle de Docker :

Docker Engine est une application client-serveur avec les composants suivants : Un serveur, qui est un type de programme fonctionnant en permanence en arrière plan, qu'on appelle un démon (« daemon » en Anglais) : la commande dockerd. Une API Rest qui définit les interfaces que des programmes peuvent utiliser pour communiquer avec le démon et le commander. Un outil en ligne de commande qui utilise l'API rest.

La sécurité

Même si des efforts sont faits pour changer les choses, le processus Docker est typiquement exécuté avec les droits root. En plus, un container lancé avec l'utilisateur root, ce qui est le cas par défaut, a les mêmes droits que le root de la machine hôte. Ça pose un problème fondamental de sécurité parce que si une faille se présente au niveau de Docker, c'est toute la machine qui est compromise. Si on arrive à s'échapper du container, on est dans le même cas.

En milieu professionnel, en tant qu'intervenant sur des serveurs de production, on m'a déjà permis d'accéder à Docker (soit en m'ajoutant au groupe « docker », soit en m'autorisant la commande « docker » via « sudo »). Les personnes qui m'ont donné l'accès à Docker, pensaient que je ne pouvais seulement créer des containers. En réalité, c'est un manque flagrant de connaissances sur le fonctionnement de Docker (ou de sudo !), et c'est désastreux du point de vue de la sécurité. Il suffit de lancer un container privilégié pour faire tout ce que l'on veut sur la machine. On peut tout à fait sortir de l'isolation du container en faisant un chroot :

docker run -it --rm --privileged -v /:/host ubuntu chroot /host /bin/bash

Même sans le flag --privileged, on peut provoquer des dégâts considérables sur la machine hôte.

Pourtant, la documentation de Docker est très claire à ce sujet :

The docker group grants privileges equivalent to the root user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.

Ce type de situation n'est pas rare, c'est une réalité de la production sur beaucoup de serveurs (hélas !).

2020-01-27-etc-shadow.png
Bien joué, les admins en herbe 😅

Dans la capture d'écran ci-dessus, je lis le contenu d'un fichier /etc/shadow, mais je peux aussi faire toute autre action bien plus dangereuse ! En plus, un outil comme auditd ne permettra pas de déterminer qui a eu l'accès au fichier. En effet, l'identité de l'utilisateur est perdue si on utilise un container : l'auid sera indéterminé (unset), étant donné que le loginuid est lui aussi indéterminé (le container est un processus fils de dockerd qui est lui même un processus fils de systemd).

Autre point important, certaines personnes exposent le port du service Docker sur l'internet public, par le moyen d'une socket TCP non protégée. Oui oui, 😱 c'est magnifique, on peut donc miner de la cryptomonnaie chez eux, on accède au reste de leur réseau (privé), on contrôle tout en fait. Un vrai petit paradis pour botnet...

En vérité, le problème n'est pas vraiment Docker, mais le manque de connaissances sur son fonctionnement (ou encore l'inconscience de certaines personnes). Et on en arrive à des installations fortement vulnérables, pour ne pas dire de véritables passoires !

La lourdeur et le manque de fiabilité de Docker

Le processus dockerd fonctionne en permanence en arrière-plan. Ce processus utilise donc des ressources qui sont perdues pour les autres charges de travail. On parle là de quelques dizaines de méga-octets occupés en mémoire vive. Ce n'est pas énorme mais c'est quand même quelque chose à prendre en compte.

Avec Docker, les containers sont des processus enfants de dockerd. Ce qui veut dire que si dockerd crash, les containers se retrouvent sans processus parents. Ils ne sont plus contrôlables par l'API de Docker.

Si pour une raison ou une autre, le processus dockerd ne fonctionne plus, on ne peut plus gérer aucun container ; c'est donc un SPOF (Single Point of Failure).

D'un autre côté, dockerd est un monstre à tout faire :

  • récupération et envoi d'images vers un container registry
  • gestion de containers (création, suppression, pause, kill, etc.)
  • construction d'images containers
  • gestion de clusters (Swarm)

On est donc bien loin de ce qu'on a traditionnellement sous UNIX : c'est à dire des outils minimalistes qui ne font que ce pour quoi ils ont été conçus, rien de plus. Avoir plus de composants logiciels induit aussi une plus grande surface d'attaque, donc on a aussi plus d'implications en terme de sécurité.

Conclusion

Docker est un outil efficace mais qui comporte malgré tout un certain nombre de faiblesses. Ces faiblesses devraient être prises au sérieux dans un contexte de production en entreprise. Nous en avons examiné quelques unes ici, il en existe certainement d'autres.

Nous verrons prochainement comment éviter ces problèmes en remplaçant Docker par d'autres outils plus récents et qui ont su prendre en considération les problématiques que nous avons abordées.

Docker reste un outil intéressant, que je réserverai plutôt pour un environnement de travail local.

PHILIPPE CHEPY

Administrateur Système et Développeur