Podman run avancé : composer une commande sûre et stable

podman run définit un contrat d’exécution : ressources autorisées, identité du processus, surface de privilèges et comportement runtime. Ce cours vous apprend à composer une commande adaptée à votre contexte, pas à mémoriser des options.

À la fin, vous saurez construire deux commandes :

• une commande dev : pratique, arrêt propre, volumes sans galères
• une commande prod : durcie, ressources limitées, privilèges minimaux

Scénario fil rouge

Vous déployez un service web nginx. Vos contraintes :

1. Protéger l’hôte : le conteneur ne doit pas consommer toute la RAM/CPU
2. Limiter l’impact d’un compromis : privilèges minimaux, filesystem restreint
3. Éviter les galères de volumes : l’UID dans le conteneur doit correspondre à l’hôte
4. Gérer proprement l’arrêt : signaux transmis, pas de processus zombies

Chaque section répond à l’une de ces contraintes.

La checklist RUN SAFE

Avant de lancer un conteneur en production, posez-vous ces 7 questions. L’acronyme RUN SAFE vous aide à n’en oublier aucune.

R — Resources

Risque : le conteneur consomme toute la RAM/CPU de l’hôte.

Options : --memory 256m --cpus 0.5 --pids-limit 100

U — User

Risque : fichiers créés appartiennent à nobody (UID 65534).

Option : --userns=keep-id

N — No-new-privs

Risque : escalade de privilèges via setuid/setgid.

Option : --security-opt no-new-privileges

S — Storage

Risque : attaquant écrit des fichiers malveillants.

Options : --read-only --tmpfs /tmp

A — Access

Risque : capabilities Linux trop permissives.

Options : --cap-drop=ALL --cap-add=...

F — Foreground

Risque : signaux non transmis, processus zombies.

Option : --init

E — Evidence

Risque : protections non appliquées (typo, override).

Vérif : podman inspect, /proc/1/status

En pratique

En dev : appliquez au minimum U (User) + F (Foreground) pour éviter les problèmes de volumes et d’arrêt.

En prod : appliquez les 7 points pour une défense en profondeur.

Détail de chaque point

R — Resources

Le problème : sans limite, un conteneur peut consommer 100% de la RAM ou du CPU de la machine, impactant tous les autres services.

La solution : définir des plafonds avec les cgroups.

Option	Ce que ça limite	Exemple
--memory	RAM maximale	--memory 256m
--cpus	Fraction de CPU	--cpus 0.5 (50% d’un cœur)
--pids-limit	Nombre de processus	--pids-limit 100
--ulimit	Ressources système	--ulimit nofile=1024:1024

Glissez pour voir

Commande type :

podman run -d --memory 256m --cpus 0.5 --pids-limit 100 nginx:alpine

U — User

Le problème : en mode rootless, le mapping UID peut créer des fichiers appartenant à nobody:65534 sur l’hôte. Impossible de les modifier sans sudo.

La solution : --userns=keep-id préserve votre UID/GID dans le conteneur.

Mode	Comportement
--userns=host	Pas de remapping (défaut)
--userns=keep-id	Recommandé — votre UID est conservé
--userns=nomap	Isolation max, mais volumes complexes

Glissez pour voir

Commande type :

podman run --userns=keep-id -v ./data:/app/data:Z alpine id
# uid=1000(bob) gid=1000(bob)

N — No-new-privs

Le problème : un binaire setuid dans le conteneur peut permettre à un attaquant de passer de user à root.

La solution : --security-opt no-new-privileges empêche d’acquérir de nouveaux privilèges après le lancement.

Vérification :

podman run --rm --security-opt no-new-privileges alpine \
  cat /proc/1/status | grep NoNewPrivs
# NoNewPrivs:     1

1 = activé (bloqué), 0 = désactivé (risque).

S — Storage

Le problème : un attaquant qui compromet le conteneur peut écrire des backdoors ou scripts de persistance.

La solution : --read-only + --tmpfs pour les dossiers qui nécessitent l’écriture.

Option	Ce que ça fait
--read-only	Filesystem en lecture seule
--tmpfs /tmp	Autorise l’écriture dans /tmp (RAM)
--tmpfs /var/run	Pour les PID files, sockets

Glissez pour voir

Commande type :

podman run --read-only --tmpfs /tmp --tmpfs /var/run nginx:alpine

A — Access

Le problème : les capabilities Linux donnent des pouvoirs spécifiques. Par défaut, Podman en accorde ~11. Certaines (CAP_SYS_ADMIN) permettent quasi tout.

La solution : retirer toutes les capabilities, puis ajouter uniquement ce qui est nécessaire.

Capability	Permet de…
NET_BIND_SERVICE	Bind sur ports < 1024
CHOWN	Changer le propriétaire des fichiers
SETUID/SETGID	Changer d’utilisateur
SYS_ADMIN	Dangereuse — quasi tout

Glissez pour voir

Pattern moindre privilège :

podman run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx:alpine

F — Foreground

Le problème : votre application devient PID 1 dans le conteneur. Si elle ne gère pas les signaux (SIGTERM), podman stop attend le timeout puis kill -9. Les processus enfants deviennent zombies.

La solution : --init ajoute un mini-init qui gère PID 1.

Avec --init	Sans --init
podman-init est PID 1	Votre app est PID 1
Signaux transmis proprement	Signaux potentiellement ignorés
Pas de zombies	Processus zombies possibles

Glissez pour voir

Commande type :

podman run --init nginx:alpine

E — Evidence

Le problème : vous pensez avoir mis les bonnes options, mais une typo ou un override les annule silencieusement.

La solution : toujours vérifier avec podman inspect et /proc/1/status.

Vérification	Commande
Mémoire	podman inspect <nom> --format '{{.HostConfig.Memory}}'
Capabilities	cat /proc/1/status | grep Cap + capsh --decode=
NoNewPrivs	cat /proc/1/status | grep NoNewPrivs
Read-only	touch /test doit échouer
User	id doit afficher votre UID

Glissez pour voir

Droit au but

Vous connaissez déjà les concepts et voulez juste les commandes ? Sautez directement à la recette qui vous intéresse :

Ressources (RAM, CPU, PIDs) Limitez la mémoire, le CPU et le nombre de processus pour protéger l'hôte.

Sécurité (capabilities, read-only) Réduisez la surface d'attaque avec le moindre privilège et un filesystem restreint.

Volumes (UID, SELinux) Évitez les problèmes de permissions avec --userns=keep-id et les suffixes :Z.

Runtime (--init, signaux) Gérez proprement l'arrêt et les processus zombies avec un init.

Ou copiez directement un profil dev ou profil prod prêt à l’emploi.

Recette 1 — Protéger l’hôte (Resources)

Un conteneur sans limite peut consommer toutes les ressources de la machine. Les options cgroups définissent des plafonds.

Limiter la mémoire

Intention : empêcher un conteneur gourmand de déclencher l’OOM killer sur d’autres processus.

podman run -d --name web-mem --memory 256m docker.io/library/nginx:alpine

Vérification (la valeur est en octets) :

podman inspect web-mem --format '{{.HostConfig.Memory}}'

Résultat

268435456

268 435 456 octets = 256 Mo. Si le conteneur dépasse, il sera tué (OOM Killed).

Suffixes mémoire

m = mégaoctets, g = gigaoctets. Exemples : --memory 512m, --memory 2g.

Limiter le CPU

Intention : éviter qu’un conteneur monopolise tous les cœurs.

podman run -d --name web-cpu --cpus 0.5 docker.io/library/nginx:alpine

Vérification (quota / période = fraction de CPU) :

podman inspect web-cpu --format 'Quota: {{.HostConfig.CpuQuota}} | Period: {{.HostConfig.CpuPeriod}}'

Résultat

Quota: 50000 | Period: 100000

50000 / 100000 = 0.5 CPU. Le conteneur utilise au maximum 50% d’un cœur.

Limiter le nombre de processus

Intention : empêcher les fork bombs.

podman run --rm --pids-limit=10 docker.io/library/alpine:3.21 sh -c \
  "for i in 1 2 3 4 5 6 7 8 9 10 11 12; do sleep 100 & done"

Résultat

sh: can't fork: Resource temporarily unavailable

Le conteneur ne peut pas créer plus de 10 processus.

Limiter les ressources système (ulimits)

Intention : restreindre les fichiers ouverts, la mémoire verrouillée, etc.

podman run --rm --ulimit nofile=64:64 docker.io/library/alpine:3.21 sh -c "ulimit -n"

Résultat

64

Format ulimit

type=soft:hard. Types courants : nofile (fichiers), nproc (processus), memlock (mémoire verrouillée).

Récapitulatif Resources

Option	Usage	Exemple
--memory	Limite RAM	--memory 512m
--cpus	Limite CPU (fraction)	--cpus 1.5
--pids-limit	Limite processus	--pids-limit=100
--ulimit	Limites système	--ulimit nofile=1024:1024

Glissez pour voir

Recette 2 — Réduire la surface d’attaque (Access + Storage + No-new-privs)

Un conteneur compromis ne doit pas pouvoir modifier le filesystem, escalader ses privilèges ou utiliser des capabilities dangereuses.

Filesystem en lecture seule

Intention : empêcher un attaquant d’écrire des fichiers malveillants.

podman run --rm --read-only docker.io/library/alpine:3.21 touch /test.txt

Résultat

touch: /test.txt: Read-only file system

Pattern recommandé : --read-only + --tmpfs /tmp pour autoriser l’écriture uniquement dans /tmp :

podman run --rm --read-only --tmpfs /tmp docker.io/library/alpine:3.21 sh -c \
  "echo test > /tmp/ok.txt && cat /tmp/ok.txt"

Résultat

test

Autres tmpfs courants

Certaines applications ont besoin de /var/run, /var/cache ou /var/log. Ajoutez-les au besoin : --tmpfs /var/run.

Bloquer l’escalade de privilèges

Ce que fait no-new-privileges : empêche un processus d’acquérir des privilèges supplémentaires via setuid/setgid (ex: un binaire setuid ne peut plus élever les droits).

Vérification de l’état :

Sans l'option

podman run --rm docker.io/library/alpine:3.21 cat /proc/1/status | grep NoNewPrivs

Résultat

NoNewPrivs:     0

Avec l'option

podman run --rm --security-opt no-new-privileges docker.io/library/alpine:3.21 \
  cat /proc/1/status | grep NoNewPrivs

Résultat

NoNewPrivs:     1

Recommandation prod

Activez toujours --security-opt no-new-privileges en production. Cette option n’a quasiment pas d’effet de bord sur les applications classiques.

Capabilities minimales

Les capabilities Linux remplacent le tout-ou-rien du root par des privilèges granulaires. Par défaut, Podman attribue environ 11 capabilities.

Pattern moindre privilège :

1. Partez de --cap-drop=ALL

2. Testez votre application — elle échoue sur une action spécifique

3. Ajoutez uniquement la capability nécessaire avec --cap-add

4. Retestez — répétez si besoin

Exemple : autoriser le bind sur les ports < 1024 (nécessite NET_BIND_SERVICE) :

podman run --rm --cap-drop=ALL --cap-add=NET_BIND_SERVICE \
  docker.io/library/alpine:3.21 cat /proc/1/status | grep CapEff

Résultat

CapEff: 0000000000000400

Décodage (pour comprendre la valeur hexadécimale) :

capsh --decode=0000000000000400

Résultat

0x0000000000000400=cap_net_bind_service

Capabilities dangereuses

Évitez CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_DAC_OVERRIDE sauf nécessité absolue — elles permettent quasi tout.

Récapitulatif sécurité

Option	Usage	Exemple
--read-only	FS lecture seule	--read-only --tmpfs /tmp
--security-opt	Options sécurité	--security-opt no-new-privileges
--cap-drop	Retire capabilities	--cap-drop=ALL
--cap-add	Ajoute capability	--cap-add=NET_BIND_SERVICE

Glissez pour voir

Recette 3 — Volumes sans galères (User)

Le problème des permissions

En mode rootless, l’utilisateur dans le conteneur est mappé vers votre UID hôte via les user namespaces. Mais ce mapping peut créer des incohérences sur les volumes montés.

Symptôme typique : fichiers créés par le conteneur appartenant à nobody ou 65534 sur l’hôte.

Les modes userns

Podman propose plusieurs modes de user namespaces :

Mode	Comportement	Cas d’usage
--userns=host	Pas de remapping (défaut en rootless)	Rarement le meilleur choix
--userns=keep-id	Votre UID/GID hôte est préservé dans le conteneur	Recommandé pour les volumes
--userns=nomap	Isolation maximale, mais volumes complexes	Conteneurs sans volume

Glissez pour voir

keep-id : le bon réflexe

podman run --rm --userns=keep-id docker.io/library/alpine:3.21 id

Résultat

uid=1000(bob) gid=1000(bob) groups=1000(bob)

Votre utilisateur hôte (UID 1000) est préservé. Les fichiers créés sur un volume monté auront les bonnes permissions.

Combiner avec SELinux (:Z ou :z)

Sur les systèmes avec SELinux (Fedora, RHEL, CentOS), ajoutez le suffixe :Z pour que le conteneur puisse accéder au volume :

podman run --rm --userns=keep-id \
  -v ./data:/app/data:Z \
  docker.io/library/alpine:3.21 touch /app/data/test.txt

Suffixe	Signification
:Z	Relabel privé (un seul conteneur)
:z	Relabel partagé (plusieurs conteneurs)
:ro	Lecture seule

Glissez pour voir

Sans SELinux

Sur Debian, Ubuntu ou Arch, les suffixes :Z et :z sont ignorés. Ils ne posent pas de problème.

Recette 4 — Runtime sain (Foreground)

Le problème du PID 1

Dans un conteneur, votre processus devient PID 1. Or, PID 1 a des responsabilités spéciales :

• Recevoir les signaux (SIGTERM, SIGINT)
• Récupérer les processus orphelins (éviter les zombies)

La plupart des applications ne sont pas conçues pour être PID 1.

La solution : —init

L’option --init ajoute un mini-init (podman-init) qui :

• Devient PID 1
• Transmet les signaux à votre application
• Nettoie les processus zombies

Sans --init

podman run --rm docker.io/library/alpine:3.21 ps aux

Résultat

PID   USER     TIME  COMMAND
    1 root      0:00 ps aux

Le processus est PID 1 — problèmes potentiels avec les signaux.

Avec --init

podman run --rm --init docker.io/library/alpine:3.21 ps aux

Résultat

PID   USER     TIME  COMMAND
    1 root      0:00 /run/podman-init -- ps aux
    7 root      0:00 ps aux

podman-init est PID 1 et gère les signaux.

Quand utiliser --init

Utilisez --init dès que votre application peut lancer des processus enfants (workers, threads, sous-processus). C’est le cas de la majorité des serveurs web, workers de queues, etc.

Méthode de vérification (Evidence)

Ne faites jamais confiance à “j’ai mis l’option”. Vérifiez systématiquement.

Vérifier les limites de ressources

podman inspect <nom> --format '
Memory: {{.HostConfig.Memory}}
CPU Quota: {{.HostConfig.CpuQuota}}
CPU Period: {{.HostConfig.CpuPeriod}}
Pids Limit: {{.HostConfig.PidsLimit}}'

Vérifier les capabilities

podman run --rm <image> cat /proc/1/status | grep Cap
# Puis décoder avec capsh --decode=<valeur>

Vérifier no-new-privileges

podman run --rm <image> cat /proc/1/status | grep NoNewPrivs
# 0 = désactivé, 1 = activé

Vérifier le user namespace

podman run --rm --userns=keep-id <image> id
# Doit afficher votre UID/GID

Vérifier read-only

podman run --rm --read-only <image> touch /test 2>&1
# Doit afficher "Read-only file system"

Deux profils prêts à copier

Profil DEV (confort + bonnes pratiques)

Objectif : développement local, arrêt propre, volumes fonctionnels.

podman run -d --rm --name web-dev \
  -p 8080:80 \
  --init \
  --userns=keep-id \
  -v ./html:/usr/share/nginx/html:Z \
  docker.io/library/nginx:alpine

Pourquoi ces options ?

Option	Raison
--init	Arrêt propre avec Ctrl+C
--userns=keep-id	Volumes sans problèmes de permissions
:Z	Compatibilité SELinux

Glissez pour voir

Profil PROD (durci + opérable)

Objectif : réduire l’impact d’un compromis, ressources bornées.

podman run -d --rm --name web-prod \
  -p 8080:80 \
  --memory 256m --cpus 0.5 --pids-limit 100 \
  --read-only --tmpfs /tmp --tmpfs /var/cache/nginx --tmpfs /var/run \
  --security-opt no-new-privileges \
  --cap-drop=ALL --cap-add=NET_BIND_SERVICE --cap-add=CHOWN --cap-add=SETGID --cap-add=SETUID \
  --init \
  --userns=keep-id \
  -v /data/nginx/html:/usr/share/nginx/html:ro,Z \
  docker.io/library/nginx:alpine

Pourquoi ces options ?

Option	Raison
--memory 256m	Protège l’hôte contre les fuites mémoire
--cpus 0.5	Évite la monopolisation CPU
--pids-limit 100	Bloque les fork bombs
--read-only	Empêche l’écriture de fichiers malveillants
--tmpfs /tmp /var/cache/nginx /var/run	Nginx a besoin d’écrire dans ces dossiers
--security-opt no-new-privileges	Bloque l’escalade via setuid
--cap-drop=ALL --cap-add=...	Moindre privilège
--init	Gestion propre des signaux
:ro sur le volume	Données en lecture seule

Glissez pour voir

Capabilities nginx

nginx a besoin de CHOWN, SETGID, SETUID pour changer d’utilisateur au démarrage (worker processes). Sans ces capabilities, il échoue au lancement.

Pièges fréquents

Ports < 1024 en rootless

Symptôme : permission denied sur le bind port 80.

Cause : en rootless, les ports < 1024 sont réservés.

Solutions :

• Utilisez un port > 1024 (-p 8080:80)
• Ou abaissez la limite système (non recommandé)

Volumes et UID

Symptôme : permission denied en écrivant sur un volume monté.

Cause : l’UID dans le conteneur ne correspond pas à l’UID des fichiers.

Solution : --userns=keep-id

Filesystem read-only qui casse l’app

Symptôme : l’application crash au démarrage avec --read-only.

Cause : l’app a besoin d’écrire dans /tmp, /var/run, etc.

Solution : ajoutez les tmpfs nécessaires (--tmpfs /tmp --tmpfs /var/run).

Capabilities insuffisantes

Symptôme : l’application échoue avec --cap-drop=ALL.

Démarche :

1. Lancez avec --cap-drop=ALL
2. Observez l’erreur (souvent explicite)
3. Ajoutez la capability minimale avec --cap-add
4. Retestez

Debug : enlever temporairement une protection

Si l’application ne fonctionne pas et vous ne trouvez pas pourquoi :

1. Retirez une option à la fois (read-only, cap-drop, etc.)
2. Testez après chaque retrait
3. Identifiez l’option bloquante
4. Cherchez le tmpfs ou la capability manquante
5. Remettez la protection avec l’ajustement

Ne jamais relâcher en prod

Ces étapes de debug sont pour l’environnement de développement. En production, trouvez la bonne configuration, ne désactivez pas les protections.

À retenir

• Checklist RUN SAFE : Resources, User, No-new-privs, Storage, Access, Foreground, Evidence
• Chaque option répond à une intention : protéger l’hôte, limiter un compromis, simplifier les volumes
• Profil dev : --init --userns=keep-id minimum
• Profil prod : ajoutez --memory --cpus --read-only --cap-drop=ALL --security-opt no-new-privileges
• Toujours vérifier avec podman inspect et /proc/1/status
• Déboguez en retirant une option à la fois, jamais en désactivant tout

Prochaines étapes

Volumes et persistance Montez des données persistantes avec bind mounts et volumes nommés.

Réseau Podman Créez des réseaux isolés, exposez vos services et configurez DNS.

Quadlet Gérez vos conteneurs comme des services avec Quadlet et systemd.

×

📖 Voir la documentation →