Conteneurisation : les différences clés entre Docker et Podman
Docker et Podman offrent des capacités similaires pour bâtir des conteneurs, mais la gestion native des accès sans droits privilégiés pourrait rendre Podman plus attrayant pour certains administrateurs.
Au moment de recourir à un logiciel de conteneurisation, la plupart des administrateurs IT et des développeurs se tournent vers Docker. C’est le constat effectué par les auteurs du rapport Stackoverflow Developer Survey 2022. « L’année dernière, nous avons vu Git se muer en un outil fondamental […]. Cette année, il semble que Docker soit en train de le devenir également pour les développeurs professionnels ». Pas moins de 68,57 % des 46 432 développeurs de profession interrogés affirment avoir amplement manipulé Docker entre 2021 et 2022.
Pourtant, un nouveau concurrent, Podman, doit offrir aux administrateurs des avantages en matière de sécurité par rapport au déploiement de base de Docker.
Cette alternative dérivée de CRI-O et mise au point par Red Hat s’exécute par défaut en tant qu’utilisateur non privilégié et sans daemon central. Sous licence Apache 2.0, Podman est le logiciel de conteneurisation couplé à RHEL.
Des différences primaires
Docker et Podman offrent bon nombre de fonctionnalités similaires. Les deux logiciels s’appuient sur les spécifications d’exécution et d’image de l’Open Container Initiative (OCI), ainsi que le I des commandes pour créer et piloter les conteneurs. Mais il existe plusieurs différences entre Docker et Podman en matière de sécurité et de dépendance à l’égard des programmes daemon.
Les deux logiciels s’appuient sur les spécifications d’exécution et d’image de l’Open Container Initiative (OCI), ainsi que le I des commandes pour créer et piloter les conteneurs.
Podman n’utilise pas de daemon central pour développer, gérer et exécuter les conteneurs OCI – il se lance au-dessus d’un système d’exploitation Linux. Plus précisément, Podman fait appel à un daemon « léger » par conteneur, intitulé conmon.
Comme son nom l’indique, Podman place les conteneurs dans un pod. Un infraconteneur maintient les espaces de noms (namespaces) spécifiques au pod et doit assurer la connexion à chaque conteneur, selon la documentation rédigée par Red Hat.
Tous les conteneurs, dont l’infraconteneur, sont connectés à un programme écrit en C, conmon. Le rôle de ce daemon léger est de superviser les processus primaires d’un conteneur, et en cas d’extinction de cet élément, de sauvegarder le code de sortie. « [Conmon] maintient également ouvert le tty du conteneur, afin qu’il puisse être attaché plus tard. C’est ce qui permet à Podman de fonctionner en mode détaché (en arrière-plan), de sorte qu’il peut s’arrêter sans entraver l’exécution de conmon », précise Red Hat.
C’est l’application d’un principe bien connu des administrateurs UNIX, c’est-à-dire un mode fork-exec, qui implique des séquences de processus parents-enfants. Podman s’exécute comme un processus. Lors de la création d’un conteneur, ce processus initial bifurque et forme un processus distinct : le conteneur démarré.
En général, avec Podman, les conteneurs peuvent être lancés avec ou sans privilèges root. Par défaut, Docker est associé à un daemon (containerd) – un processus d’arrière-plan persistant qui régit toutes les tâches de gestion des conteneurs sur l’hôte. Docker repose sur une architecture client-serveur, dans laquelle le daemon joue le rôle de serveur et les clients communiquent via l’interface de ligne de commande (CLI).
Docker utilise un daemon Windows natif pour lancer des images basées sur Windows ou Linux. Podman nécessite la version 2 du sous-système Windows pour Linux, (WSL2) disponible dans la mise à jour de mai 2020 de l’OS. Les administrateurs IT auront donc besoin d’un Windows à jour pour expérimenter cet outil. À noter que Docker Desktop propose lui aussi un support de WSL2 en option.
Sécurité
La différence la plus notable entre Docker et Podman, c’est la façon dont ces deux logiciels gèrent la sécurité du système. Par défaut, le daemon Docker requiert les accès aux droits root. Cela présente un risque évident qui croît de manière exponentielle avec chaque autorisation d’accès supplémentaire. Un conteneur Docker mal configuré pourrait accéder au système de fichiers de l’hôte sans restriction. Les développeurs et les Ops peuvent éviter ce problème en suivant certaines bonnes pratiques de base, tel le recours à des images de conteneurs provenant de fournisseurs fiables. Les utilisateurs de Docker peuvent aussi mettre en place des politiques de gestion des accès plus rigoureuses, comme le contrôle d’accès basé sur les rôles (RBAC).
Par défaut, avec Podman, les administrateurs lancent les conteneurs en tant qu’utilisateurs non privilégiés. Cela confère à Podman un avantage par rapport à Docker dans le verrouillage des environnements contre les attaques potentielles. Dans ce cas, les développeurs ne peuvent exécuter aucune commande nécessitant des privilèges d’administrateur sur le système hôte, comme le mappage de tout numéro de port privilégié inférieur à 1 024 sur l’hôte ou le port HTTP 80 par défaut.
Docker et Podman tirent tous deux parti de la fonctionnalité seccomp du kernel Linux pour activer un mode sécurisé. Cette fonction met en œuvre un mécanisme de filtrage chaque fois qu’un processus invoque un appel système, afin d’empêcher l’exécution de code malveillant. Elle réduit la surface d’attaque présentée par l’exécution de code au niveau du système.
En outre, Docker et Podman utilisent tous deux une CLI comme principale interface de gestion. Cependant, Docker utilise un point de terminaison API REST pour la communication avec le daemon. Les anciennes versions de Docker utilisent un socket TCP lié à l’adresse IP localhost. Cela présente une surface d’attaque potentielle pour un exploit de forgeage intersite. Docker a corrigé cette vulnérabilité dans la version 0.5.2 en introduisant un socket Unix, contrôlé avec les permissions Unix traditionnelles pour restreindre l’accès. Podman n’est pas sensible à ce type d’attaque, car il n’utilise pas de daemon central.
La version 3.3.0 de Podman a été publiée en août 2021 et comprenait 60 corrections de bugs et améliorations de la stabilité. Depuis la version 4.0, disponible depuis février 2022, Podman peut s’exécuter sur macOS X et redémarrer les conteneurs après le redémarrage d’un système.
Docker peut lancer le daemon en tant qu’utilisateur non root, fournissant a priori le même niveau de protection des données que Podman. Cette fonctionnalité a été introduite dans la version 19.03 du moteur Docker et est passée du statut d’expérimental à celui de courant dominant dans la version 20.10.
Dans ce cas-là, le mode rootless exécute les conteneurs et le daemon dans un namespace géré par le kernel. Les ingénieurs de Docker recommandent d’utiliser le kernel Ubuntu.
Orchestration de conteneurs
Si Docker est le logiciel de conteneurisation de facto, Kubernetes est l’orchestrateur de conteneurs le plus répandu.
Kubernetes utilise le terme pod pour définir une collection de conteneurs qui partagent certaines ressources. Comme nous l’avons vu, Podman prend en charge ce même concept en mettant en œuvre une commande pod pour gérer plusieurs conteneurs comme une seule entité.
Docker propose plusieurs options pour l’orchestration des conteneurs. Docker Swarm est l’outil de gestion de cluster natif de Docker, mais Kubernetes utilise les conteneurs Docker sous le capot, ce qui a fait de Kubernetes le choix le plus populaire pour de nombreuses organisations. Pour les déploiements Windows, les administrateurs peuvent activer Kubernetes pendant le processus d’installation. Cela leur donne un accès complet aux commandes de Kubernetes.
Avec Docker, les développeurs peuvent construire leurs applications autour du modèle CI/CD. Cela signifie que le développement et les tests peuvent avoir lieu n’importe où sur la base de simples fichiers de configuration. Quelques étapes supplémentaires pour modifier la cible de déploiement suffisent aux programmeurs pour pousser une version en production.
La version 3.0 de Podman a ajouté le support de la commande Docker compose. Auparavant, les administrateurs employaient la commande Podman play pour importer manuellement les définitions Kubernetes, qui sont écrites en YAML. Les équipes DevOps peuvent désormais charger les mêmes fichiers YAML que ceux utilisés par la commande Docker compose, ce qui facilite la transition entre les deux plateformes.
Podman et Docker sont tous deux conformes aux normes OCI pour les images, mais Podman vaut la peine d’être examiné pour ses fonctions de sécurité. Podman fournit également des commandes natives pour bâtir et tester des pods dans l’optique de lancer un environnement en production sur Kubernetes.
Docker prend en charge Kubernetes YAML, qui permet au même type de processus de développement de construire et de déployer plusieurs conteneurs dans un environnement isolé, tel qu’un ordinateur portable. Ce fichier YAML apporte le même niveau d’orchestration nécessaire pour pousser les applications vers un environnement de production Kubernetes.
Docker ou Podman ?
Du point de vue des fonctionnalités et de la sécurité, les mises à jour des deux outils les ont presque au même niveau. Bien que des différences architecturales subsistent, elles ne représentent pas d’avantages significatifs pour l’une ou l’autre approche. Pour de nombreuses organisations, tout dépendra du niveau de confort et de l’adoption par les développeurs. Étant plus jeune, Podman contient quelques bugs que les contributeurs s’efforcent de corriger. La version 4.0 inclut 50 corrections, tandis que la mouture 4.1 a mis fin à 25 bugs. Docker connaît des problèmes similaires avec son mode rootless, assez récent. De manière générale, avec Podman ou Docker, l’absence d’accès root complexifie l’administration du réseau.
La bonne nouvelle est que les deux approches permettent d’atteindre le même niveau de sécurité et de productivité pour la maintenance des applications.
