Podman, un moteur de conteneur rootless
Une alternative à Docker plus simple et sécurisée

Podman, acronyme de POD Manager, est un moteur conforme à l’Open Container Initiative. Conçu nativement pour s’intégrer dans l’environnement de pods de K8s, il se distingue surtout par sa conception sans daemon et sa capacité à fonctionner en mode rootless.
Développé à l’origine chez Red Hat et aujourd’hui soutenu par une communauté vibrante, Podman se veut une alternative sérieuse à Docker. Il reprend même son interface CLI pour simplifier la migration.
Quels trade-offs ?
Rapidement après sa création, Docker a été critiqué pour son incapacité à fonctionner en mode rootless, laissant la porte ouverte à plusieurs exploits, notamment sur les environnements Windows et macOS.
Podman a choisi une architecture totalement différente. Il n’utilise pas de daemon principal : chaque conteneur est un processus indépendant, ce qui permet un fonctionnement rootless sans friction. Il corrige ainsi les risques que pose Docker en exigeant des droits root.
En plus, Podman a été pensé pour être nativement pod-compatible, ce qui réduit les frictions à l’adoption dans les environnements Kubernetes. Il permet une gestion plus souple et complète d’un ensemble de conteneurs partageant un même contexte.
Enfin, il suit une idéologie différente : si Docker est un gros monolithe tout-en-un, Podman est un simple runtime pour conteneurs. Pas de build, pas de swarm, juste l’essentiel.
Qu’apportent les pods natifs ?
En reprenant le concept de Kubernetes, un pod est une unité applicative cohérente. Il peut contenir un ou plusieurs conteneurs partageant le même réseau, les mêmes volumes, etc. Le but est de créer nativement des unités logiques n’exposant que le strict nécessaire.
Podman ne fournit pas d’orchestrateur natif comme Docker Swarm. Il existe bien un outil de type Compose pour faciliter la migration, mais l’idée reste de s’inscrire dans une logique de cluster K8s (ou équivalent).
Que change l’absence de daemon ?
Ne pas avoir de daemon implique une architecture complètement différente. Sur Linux, Podman s’appuie fortement sur systemd pour gérer le cycle de vie des conteneurs. Par exemple, quand on utilise --restart=always
, Podman génère un service podman-restart
qui utilise systemd pour relancer les bons conteneurs au reboot.
Résultat : Podman est plus léger que Docker, et l’exécution est plus simple et plus rapide.

On peut aussi générer facilement des fichiers de service pour systemd, ce qui permet de déléguer complètement la gestion du cycle de vie des conteneurs à ce dernier.
Et côté sécurité ?
En plus du mode rootless, les User Namespaces et les Seccomp Profiles sont activés par défaut.
Le fait que les conteneurs soient rattachés à la session utilisateur permet de tracer toute activité malveillante jusqu’à l’utilisateur concerné lors d’un audit.
En résumé : renforcer la sécurité avec Podman est plus simple et plus naturel.
Et à l’usage ?
Podman a fait le choix malin de conserver une interface aussi proche que possible de celle de Docker.
Ainsi, on retrouve dans le CLI podman
les mêmes commandes (run
, stop
, rm
, inspect
, volume
, network
, etc.) avec les mêmes signatures. La doc elle-même recommande de créer un alias :
|
Même si, dans certains cas, remplacer complètement Docker demandera un peu plus.
Il existe aussi un package Podman Compose, permettant d’utiliser un fichier docker-compose.yml. Par contre, pas de Swarm ici — il faudra se tourner vers Kubernetes ou un orchestrateur équivalent.
Pour le build, il faut passer par Buildah, qui partage l’idéologie de Podman. Il permet d’écrire du shell directement pour construire les images — adieu les Dockerfiles tentaculaires.
C’est vrai : la communauté est plus petite que celle de Docker. Les outils autour sont donc un peu moins nombreux. Mais ça progresse vite.
Conclusion
Je suis pas très objectif sur ce sujet. Même si j’ai utilisé Docker dès ses débuts, j’ai toujours eu une relation un peu tendue avec son architecture et les risques de sécurité associés.
Quand j’ai découvert Podman, j’ai accroché direct. Et après avoir lu les sources, j’ai eu qu’une envie : virer Docker de tous mes environnements (ce qui a pris… quelques années).
Pareil avec les Dockerfiles : au début j’adorais, puis je me suis vite senti limité. Et comme beaucoup, je me suis retrouvé avec des monstres de 300 lignes juste pour builder une image.
Avec Buildah, j’ai retrouvé de la souplesse : du shell, un call tree, des fichiers plus petits, des dépendances partagées. Bref : la liberté.
Si vous pouvez migrer vers Podman, foncez. Presque rien ne change, et le reste se gère.
Si vous utilisez une GUI parce que le CLI de Docker est “trop compliqué”, restez sur Docker encore un moment.