Podman 6.0.0 est disponible depuis fin juin 2026, avec un billet de présentation publié début juillet. C’est une version majeure qui rompt avec plusieurs fondations historiques du projet : fin du support cgroups v1, retrait de slirp4netns et iptables, abandon de BoltDB pour SQLite, et refonte complète du parsing des fichiers de configuration.
Si vous utilisez Podman en production ou dans des pipelines CI, cette montée de version demande une vraie préparation. Ce n’est pas une simple mise à jour. Plusieurs changements sont cassants et peuvent rendre une installation inutilisable si la migration n’est pas anticipée.
En bref#
- Podman 6.0.0 publié fin juin 2026, puis détaillé dans le blog Podman début juillet.
- Breaking changes majeurs : fin du support cgroups v1, iptables, BoltDB, slirp4netns et CNI.
- Réseau : Netavark + Aardvark v2.0.0 obligatoires, Pasta devient le stack réseau rootless par défaut.
- Configuration : refonte complète du parsing des fichiers (containers.conf, registries.conf, storage.conf) avec support des drop-in et lookup unifié sous
/usr/share/containers. - CVE-2026-57231 (CVSS 7.5) : une image malveillante peut faire fuiter les variables d’environnement de l’hôte vers le conteneur. Corrigé dans Podman 5.8.4 et 6.0.0.
- Quadlet : passage majeur (sous-répertoires, API REST, nouvelles options .volume).
- Migration : nécessite Buildah 1.44.0, Skopeo 1.23, Netavark/Aardvark v2.0.0.
- Import path changé :
github.com/containers/podman/v5devientgo.podman.io/podman/v6.
Pour qui migre depuis Docker ou démarre sur Podman, la version 6 simplifie la compatibilité avec l’API Docker (support v1.44, meilleure isolation réseau par défaut). Pour les utilisateurs existants, chaque élément ci-dessous doit être vérifié avant de mettre à jour.
Les changements cassants#
Podman 6.0.0 supprime plusieurs composants qui étaient en voie de dépréciation depuis Podman 4.x et 5.x.
Réseau : fin de slirp4netns et iptables#
Le stack réseau rootless historique slirp4netns est supprimé. Podman 6 utilise Pasta comme unique backend rootless. Du côté firewall, iptables n’est plus supporté : il faut nftables. Et pour la couche réseau, CNI est définitivement remplacé par Netavark.
Concrètement, si votre distribution utilise encore iptables ou si vous dépendez de slirp4netns, Podman 6 refusera de fonctionner. La migration passe par :
- Installation du paquet
netavarketaardvark-dnsen version >= 2.0.0. - Activation de nftables.
- Configuration du backend réseau dans
containers.conf:network_backend = "netavark".
Vérifiez ces prérequis avant la mise à jour :
# Version actuelle de netavark
netavark --version
# Backend nftables actif
nft list ruleset | head -5
# Configuration Podman actuelle
podman info --format '{{.Host.NetworkBackend}}'Base de données : BoltDB remplacé par SQLite#
Podman utilisait BoltDB comme base de données interne pour les conteneurs, pods et volumes. BoltDB est supprimé dans Podman 6. La migration vers SQLite est automatique au premier lancement, mais elle est irréversible sans restauration manuelle.
Avant de mettre à jour, il est prudent de sauvegarder l’état actuel :
# Lister tous les conteneurs, pods et volumes avant migration
podman ps -a > ~/podman-containers-pre-v6.txt
podman pod ls > ~/podman-pods-pre-v6.txt
podman volume ls > ~/podman-volumes-pre-v6.txtSi vous devez revenir en arrière, ces listes vous permettront de reconstruire l’état manuellement. Il n’existe pas de commande podman system migrate --backward.
Système : fin de cgroups v1#
Podman 6 ne fonctionne que sur les systèmes utilisant cgroups v2. Les distributions récentes (Fedora 31+, Ubuntu 21.10+, Debian 11+, RHEL 9+) utilisent déjà cgroups v2 par défaut. Si vous êtes encore sur un noyau configuré en cgroups v1, Podman 6 ne démarrera pas.
Vérifiez :
stat -fc %T /sys/fs/cgroup/
# Doit retourner "cgroup2fs"Support matériel : fin des Intel Mac et Windows 10#
Podman 6 ne supporte plus les Mac Intel ni Windows 10. Les machines virtuelles créées avec podman machine sous Windows 10 devront être recréées sur un hôte compatible.
Import path modifié#
Pour les projets Go utilisant Podman comme bibliotheque, le chemin d’import change :
- Ancien :
github.com/containers/podman/v5 - Nouveau :
go.podman.io/podman/v6
Ce changement accompagne le déplacement du projet dans une organisation CNCF (Cloud Native Computing Foundation). Les consommateurs du module Go doivent mettre à jour leurs imports et régénérer leurs fichiers de dépendances.
CVE-2026-57231 : fuite de variables d’environnement#
L’avis de sécurité GHSA-4hq8-gpf5-8p68 (CVE-2026-57231, CVSS 7.5 - High) corrige une vulnérabilité où une image conteneur malveillante peut forcer Podman à transmettre les variables d’environnement de l’hôte dans le conteneur.
Fonctionnement#
Le bug exploite la réutilisation du même parseur pour les variables --env VAR (lecture depuis l’environnement hôte) et les variables définies dans le Env de la configuration d’image. Si l’image déclare une variable avec uniquement une clé, sans valeur (exemple : KEY sans =value), Podman traite cette clé comme s’il s’agissait d’un --env KEY, et va donc lire la valeur depuis l’hôte. Pire : l’opérateur * dans une variable (exemple : VAR*) provoque le passage de toutes les variables correspondant au motif. Une image peut donc exfiltrer l’intégralité des variables d’environnement de la session qui lance le conteneur.
Versions affectees#
- Podman >= v1.8.1, <= v5.8.3
- Corrigé dans Podman v5.8.4 et v6.0.0
Risque reel#
Le risque est maximal dans des environnements où des utilisateurs non privilégiés lancent des images non vérifiées, comme des pipelines CI multi-locataires ou des plateformes de type “container-as-a-service”. En local ou avec des images de confiance, l’impact est faible.
Verification#
Avant de lancer une image non signée, inspectez ses variables d’environnement :
podman image inspect --format '{{.Config.Env}}' <image>
# Si une entree ne contient pas de signe =, l'image est potentiellement malveillanteAprès mise à jour vers Podman 6.0.0, les images avec des entrées Env invalides (sans =) sont rejetées au lancement avec une erreur explicite.
Les nouveautes importantes#
Au-delà des ruptures, Podman 6 apporte plusieurs améliorations concrètes.
Quadlet refondu#
Les fichiers Quadlet connaissent leur évolution la plus importante depuis leur introduction. Les fichiers associés sont maintenant placés dans des sous-répertoires pour éviter les bugs de nettoyage. Les .volume units gagnent les options UID=, GID= et Options=. Deux nouveaux chemins de recherche sont ajoutés pour les packagers : /usr/share/containers/systemd/users et /usr/share/containers/systemd/users/${UID}.
La commande podman quadlet list dispose d’un nouvel alias podman quadlet ls et d’un filtre status=.
Podman machine amélioré#
Nouvelle commande podman machine os update pour mettre à jour l’OS de la VM. Les machines Linux montent maintenant les volumes depuis l’hôte via systemd (les VM existantes doivent être recréées). Sous Windows Hyper-V, démarrer et arrêter la VM ne nécessite plus de privilèges administrateur. Sur Mac, le provider par défaut passe de applehv à libkrun.
Toutes les commandes podman machine peuvent désormais opérer sur les VM de n’importe quel provider, indépendamment du provider courant. Une nouvelle option --import-native-ca importe les CA de confiance de l’hôte dans la VM.
Compatibilité Docker renforcée#
L’API Docker compatible passe en version v1.44. L’isolation réseau est maintenant activée par défaut, ce qui aligne Podman sur le comportement Docker. Les formats de sortie --format='{{json .Labels}}' pour podman ps, podman pod ps et podman volume ls retournent des paires key=value séparées par des virgules (comme Docker). Le MemorySwappiness passe à nil quand il n’est pas défini explicitement (comme Docker).
Nouvelles options réseau#
Les conteneurs peuvent désormais définir plusieurs adresses IP statiques en passant ip= plusieurs fois à --net. La commande podman network create supporte les routes blackhole, unreachable et prohibit, ce qui permet de bloquer l’accès de conteneurs à certains sous-réseaux sans passer par un firewall externe.
Support AMD GPU#
L’option --gpus fonctionne maintenant avec les GPU AMD, et pas seulement NVIDIA.
Migration depuis Podman 5.x#
La mise à jour vers Podman 6.0.0 n’est pas anodine. Voici une check-list pour éviter les mauvaises surprises.
Avant la mise a jour#
- Sauvegarder l’inventaire des conteneurs, pods et volumes.
- Vérifier le backend réseau : Podman 6 nécessite Netavark v2.0.0.
- Vérifier le firewall : nftables doit être actif, pas iptables.
- Vérifier cgroups : le système doit utiliser cgroups v2.
- Vérifier le stockage : si vous utilisez encore le driver overlay avec des options incompatibles, la migration SQLite peut échouer.
- Tester sur un environnement non critique avant de déployer en production.
# Script de verification pre-migration
echo "=== Backend réseau ==="
podman info --format '{{.Host.NetworkBackend}}'
echo "=== Version netavark ==="
netavark --version 2>/dev/null || echo "netavark non installé"
echo "=== Firewall ==="
iptables --version 2>/dev/null && echo "ATTENTION : iptables present"
nft --version 2>/dev/null && echo "nftables disponible"
echo "=== cgroups ==="
if [ "$(stat -fc %T /sys/fs/cgroup/)" = "cgroup2fs" ]; then
echo "cgroups v2 OK"
else
echo "ATTENTION : cgroups v1 détecté"
fi
echo "=== Stockage ==="
podman info --format '{{.Store.GraphDriverName}}'Apres la mise a jour#
Au premier lancement de Podman 6, la migration de BoltDB vers SQLite s’exécute automatiquement. Surveillez les logs :
sudo journalctl -u podman --since "5 min ago" | grep -i migrateEn cas d’échec, Podman 6 ne démarre pas. Vous devrez alors soit restaurer une sauvegarde de la base BoltDB (avant migration) soit recréer l’état à partir de votre inventaire.
Paquets necessaires#
Podman 6 doit être installé avec les versions exactes des outils compagnons :
- Buildah >= 1.44.0
- Skopeo >= 1.23
- Netavark >= 2.0.0
- Aardvark-dns >= 2.0.0
- container-libs common >= v0.68.0
Certaines distributions récentes intégreront ces versions rapidement, mais ce point dépendra du cycle de publication de chaque mainteneur. Sur des versions plus anciennes, attendez-vous à devoir utiliser les dépôts recommandés par votre distribution ou à différer la migration.
Vérifier son installation après migration#
Une fois Podman 6 installé, quelques commandes permettent de valider le bon fonctionnement :
# Version installée
podman version
# Vérifier le backend réseau
podman info --format '{{.Host.NetworkBackend}}'
# Doit retourner "netavark"
# Vérifier le backend rootless
podman info --format '{{.Host.RootlessNetworkBackend}}'
# Doit retourner "pasta"
# Vérifier le driver de stockage
podman info --format '{{.Store.GraphDriverName}}'
# Doit retourner "overlay"
# Tester un conteneur simple
podman run --rm docker.io/library/alpine:latest echo "Podman 6 OK"Conclusion#
Podman 6.0.0 est une version nécessaire. Les changements cassants étaient attendus après des années de dépréciation. Le projet en profite pour unifier son code de configuration, simplifier sa pile réseau et se préparer à une gouvernance CNCF.
Pour qui maintient Podman en production, le message est clair : ne pas monter en version sans avoir vérifié chaque prérequis. La migration n’est pas complexe, mais elle est irréversible sur certains aspects (BoltDB vers SQLite, recréation des VM).
Pour qui débute avec Podman, la version 6 est un excellent point de départ : elle corrige des années de dette technique et offre une compatibilité Docker renforcée.
Sources#
- Podman Blog : Introducing Podman v6.0.0
- GitHub : Podman v6.0.0 release notes
- GitHub Advisory : GHSA-4hq8-gpf5-8p68 (CVE-2026-57231)
- Podman Blog : Podman 6 Configuration File Changes
- Fedora Wiki : Changes/Podman6
- Podman Official Site
- Podman logo officiel
- Linuxiac : Podman 6.0 Lands With Breaking Changes
- UAPI Group : Configuration Files Specification
