Linux - Etape 03 - Rocky Linux/RHEL en pratique : Podman, sécurité native et gestion des paquets

➤ 01 - Pourquoi Podman plutôt que Docker ?
➤ 02 - SELinux et Firewalld, les outils natifs (Présentation)
➤ 03 - Gestion des paquets DNF et des dépôts
➤ 04 - Installation de Podman et de Espocrm
➤ 05 - Podman Vs Docker

01 - Pourquoi Podman plutôt que Docker ?

En 2026, Podman s'impose comme une alternative à Docker, notamment grâce à son modèle 100% gratuit et open source même sous windows. Contrairement à Docker, qui repose sur un démon (dockerd) tournant généralement avec des privilèges root, Podman adopte une architecture sans démon : chaque commande (podman run, podman build, etc.) lance un processus isolé directement sous l'utilisateur courant (en mode rootless par défaut). Cela réduit les risques de sécurité liés aux privilèges étendus et simplifie la gestion des conteneurs, tout en restant compatible avec l'écosystème Docker.

Docker conserve néanmoins des avantages pour le développement local, notamment grâce à son écosystème mature et à plusieurs années d'expérience auprès des développeurs.

02 - SELinux et Firewalld, les outils natifs (Présentation)

SELinux & Firewalld forment les deux couches de sécurité par défaut de tout système Rocky/RHEL, elles sont indépendantes l'une de l'autre.

Pour commencer c'est toujours mieux de savoir sur quelle distribution on travail...

cat /etc/os-release 2>/dev/null || lsb_release -a 2>/dev/null || uname -a
=> Cette commande permet d'afficher la version de linux utilisé quel que soit le système avec un maximum de détail. Mon système affiche : NAME="Rocky Linux" - VERSION="9.8 (Blue Onyx)"

SELinux

SELinux est un contrôle d'accès qui vient s'ajouter aux droits fondamentaux sur les fichiers et que même root n'a pas accès par défaut, c'est donc une 2ème couche de sécurité au niveau du système. Chaque action doit donc passer le contrôle Linux classique sur les droits d'accès aux fichiers et aussi le contrôle SELinux en plus pour être autorisée.

getenforce
=> Voici la première commande lié à SELinux que l'on trouve sur toutes les distributions de la famille RHEL, elle affiche le mode dans lequel on se trouve et elle propose 3 modes au total :

Enforcing : SELinux applique les règles et bloque les violations => avec journalisation et blocage.
Permissive : SELinux ne bloque pas les violations (utile pour le débogage) => avec journalisation uniquement.
Disabled : SELinux est désactivé (non recommandé) => pas de journalisation ni de blocage.

👉 Passer de Disabled à Enforcing nécessite un redémarrage.

👉 Permissive est réversible sans reboot, mais ne protège pas le système.

Firewalld

Firewalld est un pare-feu (Firewall) dynamique qui filtre le trafic réseau avant même qu'il n'atteigne un processus, c'est donc une couche de sécurité complémentaire à SELinux — qui, lui, agit une fois la requête déjà arrivée au processus. Chaque paquet réseau doit donc passer le contrôle firewalld, puis, une fois arrivé jusqu'au service, le contrôle SELinux, peut être traité.

firewall-cmd --get-active-zones

Voici la première commande liée à Firewalld que l'on trouve sur toutes les distributions de la famille RHEL, elle affiche la ou les zones actives sur le système. Une zone est un ensemble de règles associé à un niveau de confiance, et chaque interface réseau est rattachée à une zone. Voici les 3 modes les plus souvent rencontrés :

Trusted : tout le trafic est accepté, aucune restriction (zone la plus permissive).
Public : zone par défaut sur une machine exposée, seuls les services/ports explicitement autorisés passent.
Drop : tout le trafic entrant est rejeté silencieusement, sans réponse (zone la plus restrictive).

👉 Une règle ajoutée sans l'option --permanent est perdue au prochain redémarrage.

👉 Une règle --permanent n'est appliquée qu'après un firewall-cmd --reload, jamais immédiatement.

L'idée ici est donc de travailler au niveau des zones et d'affiner les droits pour chacune d'elles qui sont nécessaires, et seulement ensuite on affecte les interfaces réseau à l'intérieur, chaque interface héritant alors des droits de la zone à laquelle elle appartient.

👉 Une interface réseau appartient alors à une seule zone à la fois.

03 - Gestion des paquets DNF et des dépôts

DNF est le successeur de YUM et est le nouveau gestionnaire de paquets pour les dernières versions de Rocky/RHEL, et qui installe, met à jour et supprime des logiciels depuis des dépôts — des sources de paquets distantes, signées et vérifiées.

dnf repolist
=>Cette commande liste les dépôts actifs sur le système, on peut en voir plusieurs...

baseos — Rocky Linux 9 - BaseOS
=>C'est le socle minimal et stable du système d'exploitation : du noyau Linux, avec des outils fondamentaux...etc

appstream — Rocky Linux 9 - AppStream
=>On y trouve les applications et langages de plus haut niveau : PHP, Python, Node.js, MariaDB, Apache/Nginx ainsi que tous les modules

extras — Rocky Linux 9 - Extras
=>Ce sont des paquets additionnels maintenus par Rocky/Red Hat mais qui ne rentrent ni dans "BaseOS" car pas essentiels au système et ni dans "appstream".

il faut noter ici que le dépôt "EPEL — Rocky Linux 9" signifie Extra Packages for Enterprise Linux ("paquets supplémentaires pour Linux d'entreprise") et qu'il n'apparaît pas par défaut même avec une souscription RHEL, il faut alors le rajouter par la commande suivante :

sudo dnf install -y epel-release dnf repolist

=> On dispose à présent des 2 dépots EPEL en plus sur le système

Point de vigilance, EPEL n'est pas un produit Red Hat, ce n'est pas couvert par le support contractuel RHEL, et il n'apparaît dans aucun abonnement standard. Une entreprise qui l'utilise doit donc l'ajouter elle-même.

04 - Installation de Podman et de EspoCRM

Voici les étapes pour l'installation de podman ou de ses prérequis

podman --version
=>C'est la commande qui permet de tester le binaire podman, et s'il s'execute réellement, et qu'il est bien accessible depuis le $PATH, c'est une commande de test qui permet même de connaître la version de podman.

rpm -q podman podman-plugins
=>Permet de vérifier en même temps si podman et podman-plugins sont installés mais au niveau d'une interrogation du paquet avec sa version exacte, dans la base RPM.

ce résultat de commande permet de comprendre que uniquement podman est déjà installé sur le système.

dnf info podman
=>Permet de pouvoir récupérer la provenance exacte d'installation du dépôt du paquet.

Cette dernière commande confirme bien que Podman provient de appstream, l'un des dépôts officiels de la famille RHEL. Cette vérification est importante : elle confirme que le paquet bénéficie du support et des correctifs de sécurité fournis par Rocky/Red Hat, sans dépendre d'une source externe.

Si la commande avait plutôt indiqué epel (le dépôt communautaire ajouté manuellement plus haut), une vigilance supplémentaire aurait été nécessaire : le paquet est-il toujours activement maintenu ? A-t-il fait l'objet d'une CVE récente non corrigée ? Cette question ne se pose pas de la même façon pour un paquet appstream, couvert par l'engagement du support officiel RHEL.

sudo dnf install -y podman-plugins
=>Permet d'installer podman-plugins automatiquement sans demande de confirmation

cat /etc/subuid
cat /etc/subgid
=>Permet de vérifier les prérequis, en principe cela doit afficher quelque chose comme l'image ci dessous.

Vérification que podman est bien installé

=> Podman est bien installé et fonctionnel, même si la liste est vide.

Les étapes pour l'installation de EspoCRM

A - Préparer les 2 dossiers de données

B - Créer le fichier réseau Quadlet

C - Créer le fichier conteneur MariaDB

D - Créer le fichier conteneur EspoCRM

E - Configuration et chargement des fichiers

F - rendre la configuration persistance

A - Préparer les 2 dossiers de données

mkdir -p ~/podman-espocrm/{mariadb-data,espocrm-data,espocrm-custom,espocrm-custom-client}
mkdir -p ~/.config/containers/systemd

B - Créer le fichier réseau Quadlet "espocrm.network"

nano ~/.config/containers/systemd/espocrm.network
=>copier ensuite ce contenu ci dessous dans le nouveau fichier "espocrm.network"

[Network]
NetworkName=espocrm-net

C - Créer le fichier conteneur MariaDB "mariadb.container"

nano ~/.config/containers/systemd/mariadb.container
=>copier ensuite ce contenu ci dessous dans le nouveau fichier "mariadb.container"

[Unit]
Description=MariaDB pour EspoCRM

[Container]
Image=docker.io/library/mariadb:latest
ContainerName=espocrm-db
Network=espocrm.network
Environment=MARIADB_ROOT_PASSWORD=CHANGEZ_MOI_ROOT
Environment=MARIADB_DATABASE=espocrm
Environment=MARIADB_USER=espocrm
Environment=MARIADB_PASSWORD=CHANGEZ_MOI_APP
Volume=%h/podman-espocrm/mariadb-data:/var/lib/mysql:Z
HealthCmd=healthcheck.sh --connect --innodb_initialized
HealthInterval=20s
HealthStartPeriod=10s
HealthRetries=3

[Service]
Restart=always

[Install]
WantedBy=default.target

D - Créer le fichier conteneur EspoCRM "espocrm.container"

nano ~/.config/containers/systemd/espocrm.container
=> copier ensuite ce contenu ci dessous dans le nouveau fichier "espocrm.container"

[Unit]
Description=EspoCRM
After=mariadb.service
Requires=mariadb.service

[Container]
Image=docker.io/espocrm/espocrm:latest
ContainerName=espocrm-app
Network=espocrm.network
Environment=ESPOCRM_DATABASE_HOST=espocrm-db
Environment=ESPOCRM_DATABASE_USER=espocrm
Environment=ESPOCRM_DATABASE_PASSWORD=CHANGEZ_MOI_APP
Environment=ESPOCRM_ADMIN_USERNAME=admin
Environment=ESPOCRM_ADMIN_PASSWORD=CHANGEZ_MOI_ADMIN
Environment=ESPOCRM_SITE_URL=http://localhost:8080
PublishPort=8080:80
Volume=%h/podman-espocrm/espocrm-data:/var/www/html/data:Z
Volume=%h/podman-espocrm/espocrm-custom:/var/www/html/custom:Z
Volume=%h/podman-espocrm/espocrm-custom-client:/var/www/html/client/custom:Z

[Service]
Restart=always
TimeoutStartSec=300

[Install]
WantedBy=default.target

E - Configuration et chargement des fichiers

sudo chmod 644 ~/.config/containers/systemd/*.container ~/.config/containers/systemd/*.network
C'est la commande qui permet de changer les droits et permettre au système de lire les 3 fichiers.

cd /usr/libexec/podman/
./quadlet -dryrun -user
Ces commandes avec le paramètre -dryrun doivent maintenant charger trois fichiers sources qui ont été créé et générer trois unités propres (espocrm-network.service, mariadb.service, espocrm.service), sans aucune ligne d'erreur.

systemctl --user daemon-reload
Demande à systemd et à partir de l'utilisateur avec lequel on s'est connecté de relire l'intégralité des fichiers disponibles, y compris les fichiers Quadlet.

systemctl --user list-unit-files | grep -E "mariadb|espocrm"
Vous devez obtenir les 3 résultats comme ci-dessous

systemctl --user start mariadb.service
Cette commande peut prendre du temps, elle va télécharger une image,ne surtout pas presser Ctrl+c pour fermer la tâche...

Ici on peut supposer que la commande est peut-être bloqué, contrairement à une commande comme podman run ou il y a une barre de progression, cette commande précisément demande à podman de télécharger une image si elle n'est pas déjà en cache local, puis de démarrer un conteneur ensuite. Donc il vaut mieux attendre quelques minutes ici plutôt que de s'empresser de faire un Ctrl+c pour mettre fin à la tâche.

podman images
C'est justement cette commande qui confirmera que le téléchargement par la commande précédente s'est bien passé.

Vous devez obtenir la même chose que ci dessus.

systemctl --user status mariadb.service
C'est la commande qui va confirmer que le service mariadb est bien démarré, vous devez voir en résultat un petit point vert et un peu plus bas : active (running)

systemctl --user start espocrm.service
Cette commande peut prendre ausi du temps, elle va aussi télécharger une image,ne surtout pas presser Ctrl+c pour fermer la tâche et patienter...

podman images

Vous devez obtenir une nouvelle image, la même chose que ci dessus.

systemctl --user status espocrm.service
C'est la commande qui va confirmer que le service espocrm est bien démarré, vous devez voir en résultat un petit point vert et un peu plus bas : active (running)

podman ps -a

Vous devez voir ces 2 instances comme ci dessus espocrm, une pour la base de donnée mariadb et une autre pour l'application espocrm.

curl -I http://localhost:8080/

Cette commande avec curl confirme que la connection sur le port 8080 est ouvert en tcp afin de charger la page de connection espoCRM depuis un navigateur web, ici firefox par défaut.

Enfin en lançant firefox et en tapant http://localhost:8080/ la page de login EspoCRM doit se charger.

F - rendre la configuration persistance

sudo loginctl enable-linger rockylinux
C'est la commande qui va permettre de rendre la configuration persistante même après redémarrage, sans cette commande, mariadb.service et espocrm.service ne redémarreraient pas automatiquement après un reboot.

loginctl show-user rockylinux | grep Linger
Cette commande doit confirmer par yes comme ci-dessous que le changement a bien été pris en compte

05 - Podman Vs docker

Podman est-il déjà en train de remplacer Docker partout, et est-ce trop tard pour s'y intéresser ? Non. Docker reste dominant côté développeurs, mais Podman gagne du terrain rapidement en entreprise, en particulier sur RHEL/Rocky où il est le moteur natif.

D'un point de vue pratique, la subtilité comme énoncé plus haut est qu'il faut bien garder en tête avec quel identifiant podman a été lancé, en voici une brève différenciation au niveau pratique.

podman ne liste que ce qui a été lancé sous l'identifiant

docker liste les mêmes conteneurs aussi bien en utilisateur qu'en root