Concepts fondamentaux de Podman

Podman est un moteur de conteneurs sans daemon central qui exécute les conteneurs en mode rootless par défaut. Ce guide vous explique les concepts fondamentaux qui différencient Podman de Docker et comment ils améliorent la sécurité.

En résumé (TL;DR)

Concept	Ce que ça signifie
Daemonless	Pas de daemon central requis — chaque conteneur est un processus indépendant supervisé par conmon
Rootless	Les conteneurs tournent sans privilèges root grâce aux user namespaces (/etc/subuid, /etc/subgid)
Pods natifs	Groupe de conteneurs partageant le même réseau via un infra container (concept Kubernetes)
Compatibilité	CLI compatible Docker, images OCI, registries standard — avec quelques différences sur Compose et le réseau

Glissez pour voir

Origine du projet

Podman fait partie du projet containers/ initié par Red Hat en 2018. Il complète Buildah (build d’images) et Skopeo (copie d’images). La version 1.0 est sortie en 2019, et Podman 5.x est aujourd’hui largement utilisé en entreprise.

Architecture daemonless

Le modèle Docker (client-daemon)

Docker utilise une architecture client-serveur : le CLI docker communique avec un daemon (dockerd) qui gère les conteneurs.

Ce modèle a des implications :

Aspect	Conséquence
Daemon permanent	Un processus tourne en permanence, même sans conteneurs actifs
Accès au socket	L’accès au socket Docker (groupe docker) équivaut à des privilèges root sur la machine — documenté par Docker
Point unique de défaillance	Si dockerd crash, tous les conteneurs sont affectés

Glissez pour voir

Docker rootless existe

Docker propose un mode rootless depuis la version 20.10. L’architecture daemon reste, mais s’exécute sans privilèges root. Le socket reste cependant un vecteur d’élévation de privilèges au sein du namespace utilisateur.

Le modèle Podman (fork/exec + conmon)

Podman n’a pas de daemon central requis pour exécuter des conteneurs. Chaque commande podman run lance directement le runtime (crun/runc) :

Vérifiez qu’aucun daemon Podman ne tourne par défaut :

pgrep -a podman
# Aucun résultat = pas de daemon permanent

conmon : le superviseur léger

Chaque conteneur est supervisé par conmon (container monitor), un processus minimal qui :

• Maintient le TTY et les flux stdin/stdout/stderr
• Capture le code de sortie du conteneur
• Permet de détacher/rattacher (podman attach)

podman run -d --name demo docker.io/library/alpine:3.21 sleep 300
ps aux | grep conmon | grep -v grep

bob  3857458  /usr/bin/conmon --api-version 1 -c d070dd3e... -n demo ...

Avantage clé

Si le binaire podman est mis à jour ou redémarré, les conteneurs continuent de tourner car ils sont des processus indépendants supervisés par conmon. Source : Red Hat

Service API optionnel (podman.socket)

“Daemonless” ne signifie pas “aucun service possible”. Pour les outils nécessitant l’API Docker, Podman peut exposer un socket compatible :

# Activer le service API (rootless, à la demande)
systemctl --user enable --now podman.socket

# Vérifier le socket
ls -la /run/user/$(id -u)/podman/podman.sock

Ce service s’active à la demande (socket activation) et ne tourne pas en permanence. Documentation : podman-system-service

Comparaison daemon vs daemonless

Aspect	Docker (daemon)	Podman (daemonless)
Process permanent	dockerd toujours actif	Aucun (ou socket à la demande)
Crash du daemon	Conteneurs affectés	Aucun impact
Mise à jour CLI	Redémarrer dockerd	Transparent
Multi-utilisateurs	Daemon global partagé	Stores séparés par utilisateur
Ressources au repos	Daemon en mémoire	Rien

Glissez pour voir

Mode rootless par défaut

Le principe

En mode rootless, Podman exécute les conteneurs sans aucun privilège root. Le processus du conteneur appartient à votre utilisateur :

podman run -d --name test docker.io/library/alpine:3.20 sleep 100
ps aux | grep "sleep 100" | grep -v grep

bob  3857490  sleep 100

Le processus appartient à bob, pas à root.

User namespaces et subuid/subgid

Comment le conteneur peut-il être “root” à l’intérieur tout en étant un utilisateur normal à l’extérieur ? Grâce aux user namespaces.

Podman mappe l’UID 0 (root) du conteneur vers un UID non privilégié sur l’hôte. Cette configuration est définie dans /etc/subuid et /etc/subgid :

grep $USER /etc/subuid /etc/subgid

/etc/subuid:bob:100000:65536
/etc/subgid:bob:100000:65536

Cela signifie :

• L’utilisateur bob peut utiliser les UIDs 100000 à 165535 (65536 UIDs)
• L’UID 0 dans le conteneur = UID 100000 sur l’hôte
• L’UID 1000 dans le conteneur = UID 101000 sur l’hôte

Documentation : rootless tutorial

Modes de mapping UID (userns)

Podman propose plusieurs modes de mapping qui influencent les permissions sur les volumes :

Mode	Comportement	Cas d’usage
Par défaut	UID 0 conteneur → UID 100000+ hôte	Isolation maximale
--userns=keep-id	Votre UID réel = même UID dans le conteneur	Volumes partagés avec l’hôte
--userns=auto	Allocation automatique d’UIDs uniques	Multi-conteneurs isolés

Glissez pour voir

L’option --userns=keep-id est particulièrement utile pour éviter les problèmes de permissions sur les volumes montés depuis l’hôte.

En savoir plus : modes user namespace

Stockage rootless

En mode rootless, les images et conteneurs sont stockés dans votre home :

podman info --format "{{.Store.GraphRoot}}"

/home/bob/.local/share/containers/storage

Structure du répertoire :

Élément	Contenu
overlay/	Layers des images (système de fichiers)
overlay-images/	Métadonnées des images
overlay-containers/	Données des conteneurs
volumes/	Volumes nommés
db.sql ou bolt_state.db	Base de données (SQLite ou BoltDB selon version)

Glissez pour voir

Isolation par utilisateur

Chaque utilisateur a son propre stockage isolé. Les images téléchargées par alice ne sont pas visibles par bob. Il n’y a pas de cache partagé en rootless.

Limitations du mode rootless

Limitation	Cause	Solution
Ports < 1024	Réservés à root	sysctl net.ipv4.ip_unprivileged_port_start=80
Ping	Nécessite capability	sysctl net.ipv4.ping_group_range="0 65536"
Overlayfs	Kernel < 5.11	fuse-overlayfs (automatique)
Performances réseau	Stack userspace	Utiliser rootful si critique

Glissez pour voir

Quand utiliser le mode rootful

Certains cas nécessitent sudo podman :

• Ports privilégiés (80, 443) sans sysctl
• Montage de certains systèmes de fichiers
• Accès direct aux périphériques (/dev/…)
• Performances réseau maximales

Préférez rootless

En règle générale, utilisez toujours rootless sauf si vous avez une raison technique précise. C’est plus sûr.

Réseau rootless

Le réseau est la principale source de problèmes en mode rootless. Comprendre les différences évite beaucoup de frustration.

Pourquoi c’est différent

En rootful, Podman utilise netavark (ou CNI) pour créer des ponts réseau et configurer iptables. En rootless, ces opérations nécessitent des privilèges — Podman utilise donc une stack réseau userspace.

Stack	Mode	Caractéristiques
pasta	Rootless (défaut Podman 5+)	Performant, remplace slirp4netns
slirp4netns	Rootless (legacy)	Plus lent, compatible ancien
netavark	Rootful	Performances natives, iptables

Glissez pour voir

Symptômes courants et solutions

Symptôme	Cause	Solution
Pas de connectivité DNS	Résolveur mal configuré	Vérifier /etc/resolv.conf dans le conteneur
Port non accessible depuis l’hôte	Mapping port incorrect	Utiliser -p 8080:80 explicitement
Lenteur réseau	slirp4netns	Mettre à jour vers Podman 5+ (pasta)

Glissez pour voir

Diagnostic rapide

# Vérifier la stack réseau utilisée
podman info --format '{{.Host.NetworkBackend}}'

# Tester la connectivité depuis un conteneur
podman run --rm alpine ping -c 2 8.8.8.8

Pour une configuration avancée, voir le guide Réseau Podman.

Discussion : architecture réseau rootless

Le concept de Pod

Pourquoi les pods ?

Un Pod est un groupe de conteneurs qui partagent les mêmes namespaces (réseau, IPC). Ce concept vient de Kubernetes où il représente l’unité de déploiement de base.

Podman implémente nativement les pods — une fonctionnalité absente de Docker.

L’infra container

Quand vous créez un pod, Podman lance automatiquement un conteneur spécial appelé infra (ou pause). Son rôle : maintenir les namespaces actifs même si tous les autres conteneurs s’arrêtent.

Documentation : podman-pod-create

podman pod create --name mon-pod
podman pod ps

POD ID        NAME     STATUS   CREATED        INFRA ID      # OF CONTAINERS
363aa4fe9e83  mon-pod  Created  1 second ago   1ed785cc2461  1

Le conteneur infra a un seul rôle : maintenir les namespaces actifs même si tous les autres conteneurs s’arrêtent.

Partage du réseau

Ajoutez des conteneurs au pod :

podman run -d --pod mon-pod --name nginx docker.io/library/nginx:alpine
podman run -d --pod mon-pod --name sidecar docker.io/library/alpine:3.20 sleep 600

Listez les conteneurs du pod :

podman ps --filter "pod=mon-pod" --format "table {{.Names}}\t{{.Image}}"

NAMES               IMAGE
363aa4fe9e83-infra  localhost/podman-pause:4.9.3-0
nginx               docker.io/library/nginx:alpine
sidecar             docker.io/library/alpine:3.20

Les conteneurs partagent le même namespace réseau. Le sidecar peut accéder à nginx via localhost :

podman exec sidecar wget -qO- localhost:80 | head -3

<!DOCTYPE html>
<html>
<head>

Vérifier le partage de namespace

Les deux conteneurs utilisent exactement le même namespace réseau :

podman inspect nginx --format '{{.NetworkSettings.SandboxKey}}'
podman inspect sidecar --format '{{.NetworkSettings.SandboxKey}}'

/run/user/1000/netns/netns-a54048f2-209e-ec00-2125-8c76d38cd7e2
/run/user/1000/netns/netns-a54048f2-209e-ec00-2125-8c76d38cd7e2

Même chemin = même namespace réseau.

Cas d’usage des pods

Pattern	Description	Exemple
Sidecar	Conteneur auxiliaire qui complète l’app principale	Collecteur de logs, proxy
Ambassador	Proxy vers des services externes	Envoy, connexion DB
Adapter	Transforme les sorties de l’app	Convertisseur de métriques
Init container	Prépare l’environnement avant l’app	Migration DB, téléchargement config

Glissez pour voir

Intégration systemd : Quadlet

Pourquoi Quadlet ?

La commande podman generate systemd est dépréciée. Red Hat recommande désormais Quadlet pour intégrer les conteneurs avec systemd.

Documentation : podman-generate-systemd (déprécié)

Principe de Quadlet

Quadlet permet de définir des conteneurs comme des unités systemd via des fichiers .container :

~/.config/containers/systemd/webapp.container

[Container]
Image=docker.io/library/nginx:alpine
PublishPort=8080:80

[Service]
Restart=always

[Install]
WantedBy=default.target

# Recharger systemd et démarrer
systemctl --user daemon-reload
systemctl --user start webapp

Le conteneur démarre au boot, redémarre en cas d’échec, et s’intègre parfaitement avec journalctl.

Voir le guide Quadlet pour une configuration complète.

Compatibilité Docker

CLI compatible

Podman est conçu comme un drop-in replacement de Docker. La plupart des commandes fonctionnent à l’identique :

# Ces commandes fonctionnent avec podman ET docker
podman pull nginx
podman run -d -p 8080:80 nginx
podman ps
podman logs <container>
podman stop <container>

Vous pouvez même créer un alias :

alias docker=podman
docker --version

podman version 4.9.3

Support des Dockerfiles

Podman utilise Buildah en interne et comprend les Dockerfiles standard :

FROM alpine:3.21
RUN apk add --no-cache curl
CMD ["curl", "--version"]

podman build -t mon-image .

Registries compatibles

Podman fonctionne avec tous les registries OCI :

• Docker Hub (docker.io)
• Quay.io (quay.io)
• GitHub Container Registry (ghcr.io)
• Registries privés

API Docker

Pour les outils qui nécessitent l’API Docker, Podman peut exposer un socket compatible :

# Activer le service API (rootless)
systemctl --user enable --now podman.socket

# Vérifier le socket
ls -la /run/user/$(id -u)/podman/podman.sock

Cela permet d’utiliser des outils comme docker-compose avec Podman.

À retenir

1. Daemonless : pas de daemon central requis, mais un service API optionnel (podman.socket) existe pour la compatibilité

2. Rootless par défaut : user namespaces + subuid/subgid — option --userns=keep-id pour les volumes partagés

3. Réseau rootless : stack userspace (pasta/slirp4netns) — comportement différent du rootful

4. Pods natifs : infra container maintient les namespaces — pattern sidecar/ambassador possible

5. Compatibilité Docker : migration souvent simple, mais différences sur Compose et réseau rootless

6. Quadlet : intégration systemd recommandée (remplace generate systemd)

Écosystème containers

Podman fait partie d’un écosystème cohérent :

Outil	Utilité	Commande exemple
Podman	Run, create, exec, logs…	podman run nginx
Buildah	Build sans daemon	buildah build -t app .
Skopeo	Copier entre registries	skopeo copy docker://a oci://b
CRI-O	Runtime pour Kubernetes	Utilisé par OpenShift, K3s

Glissez pour voir

Tableau comparatif Podman vs Docker

Aspect	Docker	Podman
Architecture	Client-daemon	Daemonless (+ socket optionnel)
Sécurité par défaut	Daemon root (rootless disponible)	Rootless par défaut
Pods natifs	Non	Oui (infra container)
Intégration systemd	docker-compose	Quadlet natif
Socket/API	Toujours actif	À la demande (socket activation)
CLI	docker	podman (compatible)
Images	OCI	OCI (compatible)

Glissez pour voir

FAQ

Docker est-il rootless ?

Oui, Docker propose un mode rootless depuis la version 20.10. Cependant, ce mode n’est pas activé par défaut et nécessite une installation séparée. L’architecture daemon reste, avec un daemon et un socket utilisateur.

Pourquoi podman.socket existe si Podman est daemonless ?

“Daemonless” signifie qu’aucun daemon n’est requis pour exécuter des conteneurs via la CLI. Le socket podman.socket est un service optionnel qui expose l’API Docker pour les outils tiers (docker-compose, Portainer, etc.). Il s’active à la demande (socket activation) et ne tourne pas en permanence.

Pourquoi mes volumes ont des “permission denied” ?

En rootless, l’UID 0 du conteneur correspond à un UID non privilégié sur l’hôte (100000+). Vos fichiers appartiennent à votre UID réel (ex: 1000), pas à 100000. Solutions :

• --userns=keep-id : aligne votre UID réel avec l’UID du conteneur
• Suffixe :U sur le volume : Podman ajuste les permissions (avec précaution)

Pourquoi les pods ont un infra container ?

L’infra container (ou pause container) maintient les namespaces actifs même si tous les autres conteneurs du pod s’arrêtent. Sans lui, le namespace réseau serait détruit dès l’arrêt du premier conteneur. C’est le même principe que dans Kubernetes.

Quelle différence entre slirp4netns et pasta ?

Ce sont deux stacks réseau userspace pour le mode rootless :

• slirp4netns : legacy, plus lent, compatibilité large
• pasta : défaut depuis Podman 5, plus performant, remplace slirp4netns

Vérifiez avec podman info --format '{{.Host.NetworkBackend}}'.

Podman est-il 100% compatible Docker ?

Non. La compatibilité est élevée sur les usages CLI courants, mais des différences existent :

• Compose : utilisez podman-compose ou le mode intégré
• Réseau rootless : comportement différent (pas d’iptables)
• Certaines options docker build non supportées
• API : compatible via socket, mais pas identique à 100%

Pourquoi Quadlet plutôt que podman generate systemd ?

podman generate systemd créait des fichiers statiques qui devenaient obsolètes. Quadlet utilise des fichiers .container déclaratifs que systemd interprète dynamiquement. C’est plus maintenable et recommandé par Red Hat.

Comment savoir si je suis en rootless ou rootful ?

podman info --format '{{.Host.Security.Rootless}}'
# true = rootless, false = rootful

# Vérifier aussi le chemin de stockage
podman info --format '{{.Store.GraphRoot}}'
# ~/.local/share/containers/storage = rootless
# /var/lib/containers/storage = rootful

Prochaines étapes

Installation Installer Podman sur Linux, macOS ou Windows

Commandes essentielles Maîtriser run, ps, exec, logs et les commandes de base

Réseau Podman Configurer le réseau rootless et rootful

Quadlet Intégrer vos conteneurs avec systemd

×

📖 Voir la documentation →