Podman : conteneurs rootless et sans démon

La conteneurisation est devenue la norme pour déployer applications et services, mais le modèle historique popularisé par Docker repose sur un démon central exécuté avec les privilèges root. Ce démon pilote tous les conteneurs de l’hôte : quiconque accède à son socket obtient de fait un accès administrateur à la machine, et son arrêt interrompt l’ensemble des charges. Pour les équipes qui doivent concilier sécurité, conformité et simplicité d’exploitation, ce point de défaillance unique pose question.

Podman répond à ce problème avec une approche différente : pas de démon, exécution sans root par défaut, intégration native à systemd et compatibilité avec la ligne de commande Docker. Dans cet article, nous présentons son fonctionnement, son installation, ses usages courants (pods, Quadlet), les changements de la version 6 et les bonnes pratiques pour l’adopter en production.

Qu’est-ce que Podman ?

Podman (pour Pod Manager) est un outil open source, sous licence Apache 2.0, qui permet de gérer des conteneurs, des pods et des images conformes aux standards de l’OCI (Open Container Initiative). Initié par Red Hat, le projet est aujourd’hui attribué sur son site officiel à Podman Container Tools, une série de projets de la Linux Foundation. Il est disponible sur Linux, où il fonctionne nativement, ainsi que sur macOS et Windows via une machine virtuelle gérée par la commande podman machine.

Au moment de la rédaction, la dernière version stable est Podman 6.1.4 (octobre 2026), la branche 6.x ayant été publiée en juin 2026. Une interface graphique, Podman Desktop, complète l’outil en ligne de commande pour les postes de développement.

Ses atouts principaux :

Sans démon : chaque conteneur est un processus enfant lancé directement par la commande podman, sans service central permanent.
Rootless : un utilisateur standard peut exécuter des conteneurs sans aucun privilège administrateur sur l’hôte.
Compatible Docker : la syntaxe des commandes est quasi identique (run, ps, build, pull…), et une API compatible Docker peut être exposée via un socket.
Pods : regroupement de plusieurs conteneurs partageant le même espace réseau, sur le modèle de Kubernetes.
Intégration systemd : avec Quadlet, les conteneurs se déclarent comme de véritables services système.

Architecture et fonctionnement

Podman s’appuie sur un ensemble de briques spécialisées plutôt que sur un démon monolithique :

Le runtime OCI (crun ou runc) crée effectivement le conteneur à partir des namespaces et des cgroups du noyau Linux.
conmon, un petit moniteur, surveille chaque conteneur, conserve ses journaux et son code de sortie une fois la commande podman terminée.
Netavark et Aardvark-dns gèrent les réseaux et la résolution de noms entre conteneurs ; en mode rootless, pasta fournit la connectivité réseau sans privilèges.
containers/storage et containers/image, partagés avec Buildah et Skopeo, gèrent le stockage des couches et les échanges avec les registres.
Une base SQLite conserve l’état des conteneurs.

En mode rootless, Podman utilise les user namespaces : l’utilisateur root à l’intérieur du conteneur correspond à un UID non privilégié sur l’hôte, grâce aux plages déclarées dans /etc/subuid et /etc/subgid. Une évasion de conteneur ne donne donc accès qu’aux droits de cet utilisateur, et non à ceux de root.

Installation

Podman est empaqueté dans la plupart des distributions Linux. Les versions fournies par les dépôts varient selon la distribution et sont souvent en retard sur la branche 6.x : vérifiez la version installée avec podman --version. Sur macOS et Windows, l’installeur officiel ou Podman Desktop installe le client puis crée une machine virtuelle Linux.

# Fedora, RHEL, AlmaLinux, Rocky Linux
sudo dnf install -y podman

# Debian, Ubuntu
sudo apt update && sudo apt install -y podman

# macOS (Homebrew), puis création de la machine virtuelle
brew install podman
podman machine init
podman machine start

# Vérifications
podman --version
podman info | grep -i -E "rootless|cgroupVersion|networkBackend"
grep "$USER" /etc/subuid /etc/subgid

Utilisation au quotidien

Les commandes reprennent celles de Docker : un administrateur habitué à docker run est opérationnel immédiatement. Lancées par un utilisateur standard, elles s’exécutent en mode rootless ; les images sont alors stockées dans ~/.local/share/containers. Quelques réflexes à connaître :

Noms d’images complets : préférez docker.io/library/nginx à nginx, afin de savoir exactement de quel registre provient l’image (les registres de recherche sont définis dans registries.conf).
Ports privilégiés : en rootless, un conteneur ne peut pas publier un port inférieur à 1024 sans réglage du noyau ; publiez par exemple sur 8080 et placez un reverse proxy devant.
Volumes : l’option :Z applique le bon contexte SELinux au répertoire monté sur les distributions qui l’activent.

Les pods. Un pod regroupe plusieurs conteneurs qui partagent la même pile réseau et communiquent via localhost, exactement comme dans Kubernetes. La commande podman kube generate exporte un pod en manifeste YAML Kubernetes, et podman kube play fait l’inverse : c’est un moyen pratique de prototyper localement avant un déploiement sur un cluster.

Quadlet : les conteneurs comme services systemd. Faute de démon, ce n’est pas Podman qui redémarre les conteneurs au boot, mais systemd. Quadlet permet de décrire un conteneur dans un fichier .container (ou .pod, .volume, .network, .kube) placé dans /etc/containers/systemd/ pour le système, ou dans ~/.config/containers/systemd/ pour un utilisateur. Systemd génère alors une unité de service classique, avec journaux dans journald, dépendances et redémarrage automatique.

Exemple : un serveur web rootless géré par systemd, avec mise à jour automatique de l’image.

# Premier conteneur rootless
podman run -d --name web -p 8080:80 docker.io/library/nginx:stable
podman ps
podman logs web

# Pod regroupant une application et sa base de données
podman pod create --name app -p 8080:80
podman run -d --pod app --name db -e POSTGRES_PASSWORD=changeme docker.io/library/postgres:17
podman kube generate app > app.yaml

# Service Quadlet utilisateur : ~/.config/containers/systemd/web.container
[Unit]
Description=Serveur web Nginx (Podman)

[Container]
Image=docker.io/library/nginx:stable
PublishPort=8080:80
AutoUpdate=registry

[Service]
Restart=always

[Install]
WantedBy=default.target

# Activation du service
systemctl --user daemon-reload
systemctl --user start web.service
loginctl enable-linger $USER

# API compatible Docker (outils tiers, docker-compose)
systemctl --user enable --now podman.socket

Podman 6 : ce qui change avant de mettre à jour

La version 6.0, publiée en juin 2026, supprime plusieurs couches héritées. Avant de migrer un serveur, vérifiez les points suivants :

cgroups v1 n’est plus pris en charge : l’hôte doit utiliser cgroups v2.
CNI et slirp4netns sont retirés : le réseau repose sur Netavark, et sur pasta en mode rootless.
iptables n’est plus géré par Netavark, qui utilise nftables.
BoltDB disparaît au profit de SQLite ; le projet Fedora recommande de passer d’abord par Podman 5.8 pour migrer la base d’état.
Quelques comportements par défaut évoluent : podman commit met désormais le conteneur en pause, et podman volume prune ne supprime plus que les volumes anonymes inutilisés (option --all pour l’ancien comportement).

La version apporte aussi la prise en charge des GPU AMD via --gpus, une option --dry-run pour podman volume prune, la commande podman machine os update et des améliorations de Quadlet.

Podman face aux alternatives

Docker Engine : écosystème très large et Docker Compose natif, mais architecture fondée sur le démon dockerd. Un mode rootless existe, sans être le fonctionnement par défaut. Podman reprend la même syntaxe et peut servir de remplaçant direct dans la plupart des cas ; podman compose s’appuie sur un fournisseur externe (docker-compose ou podman-compose).
containerd et nerdctl : containerd est le runtime de référence des clusters Kubernetes ; nerdctl lui ajoute une CLI proche de Docker. Ce couple vise surtout l’orchestration, quand Podman cible l’hôte unique et le poste de développement.
LXC/Incus : conteneurs « système » qui hébergent une distribution complète, plus proches de la machine virtuelle légère que du conteneur applicatif.

Pour gérer Podman en interface web, Portainer et Cockpit (module cockpit-podman) savent tous deux piloter des conteneurs Podman.

Bonnes pratiques

Restez en rootless et créez un compte de service dédié par application ; n’utilisez sudo podman que pour les rares cas qui l’exigent réellement.
Déclarez vos services avec Quadlet plutôt qu’avec des scripts ou l’ancienne commande podman generate systemd, et activez loginctl enable-linger pour que les services utilisateur démarrent sans session ouverte.
Épinglez vos images sur un tag précis (voire un digest), utilisez des noms complets et limitez les registres autorisés dans registries.conf.
Scannez vos images avant déploiement avec un outil comme Trivy, puis automatisez les mises à jour avec podman auto-update et la clé AutoUpdate=registry.
Durcissez les conteneurs : --read-only, --cap-drop=all en ne réajoutant que les capacités nécessaires, limites de ressources (--memory, --cpus) et SELinux actif sur l’hôte.
Protégez le socket API s’il est activé : il donne le contrôle des conteneurs de l’utilisateur concerné et ne doit jamais être exposé sur le réseau sans authentification.
Testez la montée de version vers Podman 6 sur un hôte de recette (cgroups v2, nftables, migration SQLite) avant la production.

Conclusion

Podman apporte une réponse pragmatique aux limites du modèle à démon : chaque conteneur est un processus surveillé par systemd, exécuté sans privilèges root, avec une syntaxe que les équipes connaissent déjà. Les pods et l’export en YAML facilitent le passage vers Kubernetes, tandis que Quadlet en fait un excellent choix pour héberger des services sur un serveur unique. Pour débuter, partez d’un service existant, réécrivez-le en fichier .container et comparez l’exploitation au quotidien. Si vous découvrez les conteneurs, notre cours Introduction à Docker pose les bases, directement transposables à Podman.

Partagez cet article !