Podman est-il une alternative viable à Docker ?

Publié le

Podman est un outil proposé par RedHat qui permet de gérer des containers. Il se place donc en concurrent direct de Docker. Podman est d’ailleurs compatible avec Docker. Dan Walsh de chez RedHat explique qu’on peut très bien créer un alias dans le shell pour remplacer Docker par Podman : alias docker=podman.

Les images de containers que Podman manipulent sont au même format que celles de Docker. Ce sont des images au format OCI (Open Container Initiative). Les container registries habituels fonctionnent donc aussi avec Podman.

Les avantages de Podman par rapport à Docker

Un des gros avantages de Podman sur Docker, c’est qu’il n’a pas besoin d’exécuter un service en arrière plan en permanence pour  gérer les containers. Comme il n’y a pas de services centralisés, il n’y a pas de SPOF (Single Point of Failure) lors de l’exécution de containers sur une machine.

Le principe de moindre privilège est respecté

Docker lance les containers avec l’utilisateur « root » par défaut. D’ailleurs le processus dockerd (le daemon Docker), fonctionne lui même avec l’utilisateur « root ». Dans le cas de Docker, que ce soit au niveau du runtime ou au niveau des containers, on se retrouve souvent avec des processus qui ont bien plus de droits que nécessaire. Ce fonctionnement peut même facilement amener à des failles de sécurité énormes !

Comme dit précédemment, Podman ne fonctionne pas avec un service centralisé, comme le fait Docker. Les containers que Podman gèrent sont donc exécutables avec n'importe quel utilisateur (root mais aussi les utilisateurs non privilégiés). On parle là d'un fonctionnement rootless.

Podman gère les informations qui concernent les images et les containers en respectant le cloisonnement des utilisateurs. Un utilisateur de Podman ne verra donc pas les containers lancés par un autre utilisateur de Podman sur une même machine.

Une meilleure isolation des utilisateurs

Podman propose une meilleure isolation que Docker au niveau de la gestion des utilisateurs. Avec Podman, il est tout à fait possible de lancer un container dans lequel le processus est « root », sur la machine hôte cet utilisateur sera pourtant non privilégié. D’une façon générale, les utilisateurs du systèmes ne sont plus partagés avec les utilisateurs dans le container. Si une faille de sécurité se présente et qu’il devient possible de sortir du container, un attaquant ne se retrouvera pas avec les droits d'administrateur. Avec Podman, on a une meilleure mitigation de ce type de failles.

L'Audit log est de nouveau correct

Avec Docker, l’audit d’une ressource ne fonctionnera pas correctement. Par exemple, si on active l’audit log sur un fichier comme /etc/shadow, il ne permettra pas de déterminer qui a eu accès au fichier, si cet accès s’est fait depuis un container géré par Docker. Avec Podman, cette information sera bien présente.

Sans entrer dans les détails, cette situation est due au fonctionnement même de Docker sous forme de client/serveur. Un utilisateur de Docker (l’outil en ligne de commande) utilise l’API REST de dockerd pour créer les containers. Ce container ne contient pas l’UID (le loginuid en fait) de l’utilisateur qui l’a créé, car c’est dockerd qui s’en est chargé et non la commande « docker »… Podman n’est par définition pas concerné par cette situation.

Pour approfondir ce sujet, il existe de nombreux articles qui traitent de cette problématique spécifique, parmi lesquels :

Inconvénients de Podman par rapport à Docker

Podman n’a pas été packagé pour fonctionner sous Windows ou macOS. Cet outil ne fonctionne que sous Linux. C’est un choix délibéré de l’équipe de développement, ce qui fait sens puisqu’avec Podman on exécute uniquement des containers Linux. Il est toujours possible de rendre Podman utilisable à travers une socket et de l’installer dans une machine virtuelle Linux. On pourra alors le contrôler malgré tout depuis macOS par exemple. Ce fonctionnement se rapproche de ce que fait Docker sous ces OS, mais reste à mettre en place manuellement.

Podman ne fonctionne pas avec docker-compose, cependant, un outil existe pour avoir des fonctionnalité presque identiques : c'est podman-compose. Certains préconisent d’utiliser les Pods pour remplacer docker-compose, et c'est l'approche de podman-compose. Je ne suis pas d’accord avec cette façon de faire, ce n’est pas vraiment équivalent… Techniquement c’est faisable (et podman-compose le fait), mais sémantiquement ce n’est pas la même chose. En effet un Pod est une unité d’exécution de base (autrement dit, un Pod = une instance d'un service), alors qu’avec un docker-compose on définit très souvent un service avec ses dépendances externes. Par ailleurs, et c'est une limite de podman-compose, le réseau n'est pas géré de la même façon dans un pod que dans un ensemble de containers gérés par docker-compose.

Podman, exécute... des Pods

Bonus : Podman permet de gérer des containers mais son nom fait directement référence aux Pods qu'il permet de gérer également. Les Pods sont l’unité d’exécution de base dans Kubernetes.

Pour faire simple, un Pod est un ensemble de containers qui travaillent ensemble. Les containers d’un même pod partagent le même localhost. Le fonctionnement par Pods permet de mettre en place différents patterns de fonctionnement sur lesquels nous aurons l’occasion de revenir prochainement dans d'autres articles.

La définition d'un Pod dans Podman tend à être compatible avec celle de Kubernetes.

Conclusion

Podman est un outil relativement récent. Il apporte de grands avantages par rapport à Docker, comme le fait qu’il ne nécessite plus de services en arrière plan pour fonctionner, ou encore une meilleure isolation des containers avec leur hôte. Globalement, Podman propose un bien meilleur modèle de sécurité que Docker.

Podman est déjà prêt pour la production. Par contre il impose certaines limites comme le fait qu’il ne fonctionne pas nativement sous macOS ou Windows (en fait Docker non plus, mais ce dernier facilite les choses en proposant un installateur pour ce cas de figure). Ce dernier point sera peut être limitant pour certains utilisateurs…

PHILIPPE CHEPY

Administrateur Système et Développeur