Podman, KVM et conteneurs : un guide pratique pour une virtualisation sécurisée

Informatec Digital » Ressources » Podman, KVM et conteneurs : Guide pratique de virtualisation sécurisée

Lorsqu'on met en place un environnement de conteneurs robuste sous Linux, une question se pose immédiatement : dans quelle mesure est-il sûr de se fier uniquement aux conteneurs, et quand est-il conseillé de passer à KVM ou aux micro-VM ? Dans les environnements d'entreprise où Docker, Podman, LXC, les machines virtuelles KVM et divers hyperviseurs coexistent, une bonne compréhension du modèle d'isolation est essentielle pour éviter les erreurs.

De plus, des scénarios complexes sont fréquents, comme l'utilisation de Docker Desktop ou de Podman au sein d'une machine virtuelle VirtualBox ou KVM , où plusieurs niveaux de virtualisation (imbriqués ou non) entrent en jeu, et où il est facile de rencontrer des erreurs telles que « KVM n'est pas activé sur l'hôte ». Organisons tous ces éléments — conteneurs, machines virtuelles, Podman, KVM, réseau et sécurité — et voyons comment les combiner pour obtenir une virtualisation véritablement sécurisée et pratique.

Virtualisation classique avec KVM et machines virtuelles

Le fondement de cette architecture repose sur la virtualisation complète des systèmes d'exploitation à l'aide d'hyperviseurs tels que KVM, Xen ou ESXi . Dans ce cas, le matériel physique exécute un hyperviseur chargé de « diviser » la machine en plusieurs machines virtuelles indépendantes.

Dans ce modèle, chaque machine virtuelle démarre son propre noyau et son propre système d'exploitation invité , indépendamment de l'hôte. L'hyperviseur (par exemple, KVM, intégré au noyau Linux) fait office de passerelle entre le matériel et les machines virtuelles, et assure une isolation stricte entre eux.

On distingue généralement deux types d'hyperviseurs : les hyperviseurs de type 1, ou hyperviseurs « bare metal », qui s'exécutent directement sur le matériel, et les hyperviseurs de type 2, hébergés sur un système d'exploitation existant. VirtualBox ou VMware Workstation sont des hyperviseurs de type 2 , tandis qu'un KVM géré par libvirt sur un serveur Linux se rapproche davantage d'un scénario de type 1, même s'il partage l'espace avec l'hôte.

Le principal avantage de cette approche réside dans le fait que chaque machine virtuelle dispose de sa propre pile logicielle complète : noyau, espace utilisateur, services, réseau et stockage . Ceci offre une grande flexibilité et la possibilité d’exécuter différents systèmes d’exploitation et versions de noyau sur une même machine physique.

Pour gérer ces plateformes virtualisées sous GNU/Linux, libvirt est presque toujours utilisé comme API d'orchestration , sur laquelle sont pris en charge des outils graphiques et en ligne de commande, ou des projets plus importants comme OpenStack, qui construit des clouds complets en combinant des machines virtuelles, du matériel physique et des conteneurs.

Configuration matérielle requise et problèmes courants liés aux KVM

Avant d'exécuter KVM ou d'utiliser des solutions qui en dépendent (comme certaines configurations Docker Desktop ou micro-VM), vous devez vous assurer que le processeur prend en charge la virtualisation matérielle (VT-x sur Intel ou SVM/AMD-V sur AMD) et qu'elle est activée dans le BIOS/UEFI.

Sous Linux, une vérification rapide permet de déterminer si la commande `grep -E 'svm|vmx' /proc/cpuinfo` ne renvoie aucun résultat, ou si l'option est toujours désactivée dans le firmware. Dans ce cas, KVM ne fonctionnera pas. De plus, dans les scénarios où des machines virtuelles sont exécutées à l'intérieur d'une autre (virtualisation imbriquée), l'hyperviseur de niveau supérieur doit explicitement exposer ces extensions à la machine virtuelle invitée.

En cas de problème, des messages typiques apparaissent, comme la fameuse fenêtre contextuelle Docker Desktop dans RHEL 9 au sein de VirtualBox : « KVM n’est pas activé sur l’hôte ». Le problème ne vient pas directement de Docker ou de RHEL, mais plutôt du fait que la machine virtuelle VirtualBox ne reçoit pas les extensions de virtualisation nécessaires pour exécuter KVM en son sein.

Les commandes telles que `modprobe kvm` ou `modprobe kvm_amd / kvm_intel` devraient charger les modules du noyau sans message d'erreur. Si `dmesg` ne renvoie aucune information pertinente, ou si `lsmod | grep kvm` n'affiche que `kvm` et `irqbypass`, et que les modules spécifiques au processeur sont absents, il est très probable que la virtualisation matérielle ne soit pas accessible au système invité ou qu'elle soit désactivée dans le firmware.

Dans ces cas de figure, même si toutes les fonctionnalités sont activées dans la machine virtuelle, si VirtualBox ne propose pas la virtualisation imbriquée ou est mal configuré, KVM ne fonctionnera pas . La solution consiste à vérifier la configuration de l'hyperviseur hôte (VirtualBox, VMware, etc.) et à activer la virtualisation imbriquée si elle est disponible.

Conteneurs : virtualisation légère au niveau du système d’exploitation

Contrairement aux machines virtuelles traditionnelles, les conteneurs proposent une approche différente : ils n’émulent pas tout le matériel, mais réutilisent plutôt le noyau hôte et isolent les processus et les ressources à l’aide des fonctions du noyau Linux.

Un conteneur est essentiellement un ensemble de processus encapsulés à l'aide d'espaces de noms et de cgroups . Au sein de cet « environnement », l'application croit s'exécuter sur sa propre machine, avec son propre système de fichiers, ses interfaces réseau et ses PID, mais en réalité, elle partage le noyau avec l'hôte.

Les conteneurs offrent des performances quasi natives car ils ne nécessitent ni second noyau ni émulation matérielle complète . La surcharge est minimale : juste suffisante pour monter les espaces de noms, limiter les ressources avec les cgroups et appliquer les politiques de sécurité (seccomp, AppArmor, SELinux, etc.).

Cependant, cette conception a une conséquence importante : toutes les charges de travail partagent le même noyau physique . Une vulnérabilité grave dans ce noyau peut soudainement devenir un vecteur d’échappement potentiel pour tous les conteneurs exécutés sur ce nœud.

C’est pourquoi on dit souvent que l’isolation des conteneurs n’est pas « absolue » comme celle d’une machine virtuelle . Si quelqu’un parvient à exploiter une faille critique du noyau, les espaces de noms cessent de constituer une barrière efficace et la frontière entre les conteneurs et les hôtes peut être franchie.

Espaces de noms et cgroups : les fondements de l’isolation des conteneurs

Sous Linux, l'isolation des conteneurs repose sur deux piliers principaux : les espaces de noms pour séparer les vues du système et les cgroups pour limiter et comptabiliser les ressources.

Les espaces de noms isolent les éléments tels que les PID, le réseau, les points de montage, la communication interprocessus, le nom d'hôte (UTS) et les utilisateurs . Ainsi, un processus ne « voit » que les processus, les interfaces réseau, le système de fichiers et le nom d'hôte de son propre espace de noms, ce qui lui donne l'impression d'exécuter un système différent.

De leur côté, les cgroups permettent de spécifier la quantité de CPU, de mémoire, d'E/S disque, le nombre de processus, etc., qu'un conteneur peut consommer . Cela empêche une charge incontrôlée de surcharger l'ensemble de l'hôte, ce qui est essentiel lors du partage de nœuds entre équipes ou projets.

Il est toutefois essentiel de comprendre que les espaces de noms et les cgroups ne constituent pas à eux seuls un système de sécurité complet . Ils n'empêchent pas l'exploitation des vulnérabilités du noyau, ne filtrent pas les appels système et ne gèrent pas les politiques d'accès de manière granulaire. Ils en constituent la base, mais doivent être renforcés.

La méthode la plus judicieuse pour renforcer la sécurité de l'environnement consiste à combiner les filtres d'appels système avec seccomp, les politiques MAC (AppArmor ou SELinux) et une réduction drastique des capacités des processus, idéalement avec des espaces de noms utilisateur et le mode sans root pour minimiser les dégâts si quelqu'un parvient à s'échapper du conteneur.

Menaces de sécurité sur les plateformes de conteneurs

Dans une véritable plateforme de conteneurs, la surface d'attaque est répartie sur plusieurs couches : le noyau et l'environnement d'exécution (runc, containerd, CRI-O), la chaîne d'approvisionnement en images, la configuration du conteneur/orchestrateur et l'infrastructure sous-jacente (cloud, stockage, IAM, réseau).

Les vecteurs d'attaque courants comprennent les vulnérabilités logicielles du noyau ou de l'environnement d'exécution des conteneurs, l'utilisation d'images non sécurisées ou non maintenues, les erreurs de configuration dans Kubernetes ou Docker (conteneurs privilégiés, montages d'hôtes dangereux, modes réseau excessivement ouverts) et les failles de sécurité dans les registres ou les pipelines CI/CD.

Dans de nombreux incidents réels, il n'y a pas un seul « bug magique », mais plutôt une combinaison de vulnérabilités connues et de configurations laxistes : conteneurs exécutés en tant que root, utilisation de l'option --privileged, montage du système de fichiers hôte dans le conteneur et absence de seccomp ou de MAC.

À cela s'ajoute le problème de la chaîne d'approvisionnement : les images de base publiques contiennent souvent des vulnérabilités CVE, des paquets obsolètes et des dépendances mal contrôlées . Il est relativement facile pour un logiciel malveillant de s'y infiltrer ou pour une bibliothèque compromise de rester inactive jusqu'à ce que les conditions soient réunies pour son exécution.

Par conséquent, en production, ce n'est pas optionnel : vous devez analyser les images à la recherche de vulnérabilités avec des outils comme Trivy, Clair ou Grype , contrôler les registres utilisés (Harbor, Quay, GHCR avec des politiques) et signer/vérifier les images avant de les déployer dans un cluster.

Docker contre Podman : Impact sur le modèle de menaces

Dans le monde des conteneurs d'applications, Docker et Podman couvrent des fonctions similaires, mais leur architecture diffère considérablement, ce qui modifie le modèle de sécurité que nous utilisons sur un hôte.

Docker, en mode root classique, repose sur un démon central (dockerd) exécuté en tant que root . L'interface de ligne de commande communique avec ce démon via /var/run/docker.sock ou via TCP, et c'est ce processus privilégié qui crée et supprime les conteneurs, gère les images, les réseaux et les volumes, et interagit avec les registres.

Cela signifie que toute personne ayant accès au socket Docker dispose pratiquement d'un accès root à l'hôte , car elle peut lancer des conteneurs privilégiés, monter des systèmes de fichiers arbitraires et modifier la configuration critique. Le démon devient ainsi un point de défaillance unique.

Podman, en revanche, a été conçu comme un moteur de conteneurs sans démon, aussi « natif » que possible de Linux . Il n'y a pas de processus central permanent ; les conteneurs sont contrôlés par l'utilisateur ou par systemd, et l'intégration avec ce dernier permet de les gérer via des unités de service.

Cette approche correspond mieux au modèle Unix selon lequel « chaque processus appartient à l'utilisateur qui le lance » et évite de dépendre d'un démon nécessitant des privilèges élevés . De plus, Podman offre une compatibilité avec les commandes Docker, simplifiant ainsi la migration (il est même possible de créer un alias `docker=podman` dans les environnements où l'installation de Docker CE n'est pas souhaitée).

Mode sans privilèges et espaces de noms utilisateur

L'une des principales avancées pratiques pour réduire l'impact d'une éventuelle évasion de conteneur est le mode sans privilèges root combiné aux espaces de noms utilisateur . La question à laquelle cela vise à répondre est : « Que se passe-t-il si le conteneur s'échappe ? »

Les espaces de noms utilisateur permettent de réassocier l'UID 0 du conteneur à un UID non privilégié sur l'hôte . Autrement dit, à l'intérieur du conteneur, l'application se considère comme l'utilisateur root, mais du point de vue de l'hôte, ce processus est en réalité un utilisateur standard avec une plage de sous-UID/sous-GID attribuée.

Ainsi, même si un attaquant obtient les privilèges root à l'intérieur du conteneur et parvient à exploiter une faille du noyau ou de l'environnement d'exécution, il se retrouve sur l'hôte avec un compte utilisateur non privilégié . Il ne peut ni écraser les fichiers binaires root, ni monter des systèmes de fichiers sensibles, ni manipuler des périphériques pour lesquels il ne dispose pas des privilèges nécessaires.

Podman a été conçu dès le départ avec ce modèle en tête : conteneurisation sans privilèges root par défaut chaque fois que cela est possible , utilisation de SELinux/AppArmor et des cgroups même sans privilèges root, et une forte emphase sur la minimisation des privilèges structurels.

Docker propose désormais un véritable mode sans privilèges root , où dockerd et les conteneurs résident dans un espace de noms utilisateur, contrairement à l'ancien système userns-remap où le démon conservait les privilèges root. Du point de vue de la sécurité, cela empêche une exploitation de la vulnérabilité de dockerd d'obtenir automatiquement un accès root à l'hôte.

Réseaux de conteneurs avec Podman : interfaces bridge, host, macvlan et rootless

Un autre élément important pour la sécurité et le bon fonctionnement est la couche réseau du conteneur . Podman propose différents mécanismes de connectivité, notamment pour les scénarios sans privilèges root.

Podman 4 a introduit netavark, un pilote réseau qui suit le modèle CNI pour fournir aux conteneurs des adresses IP sur les réseaux de pont, les macvlans, etc. Avec netavark, les conteneurs rootful se connectent généralement par défaut à un réseau appelé « podman » associé à un pont Linux (podman0) sur l'hôte, avec l'adressage 10.88.0.0/16.

Ce réseau pont par défaut assure une connectivité Internet de base via des règles SNAT et permet d'exposer les ports des conteneurs à l'hôte à l'aide de l'option `-po --publish`, qui génère des règles DNAT dans iptables/nftables. Pour assurer la compatibilité avec Docker, ce réseau n'exécute pas de serveur DNS interne.

Nous pouvons également créer des réseaux pontés personnalisés , qui isolent des groupes de conteneurs et fournissent un DNS interne. Cela permet aux conteneurs de résoudre des noms au sein de leur réseau privé, facilite la séparation des services qui ne doivent pas interagir et offre un meilleur contrôle sur la MTU, les pare-feu et d'autres fonctionnalités.

Dans les environnements plus avancés, il est possible d'utiliser les réseaux macvlan ou ipvlan pour connecter directement les conteneurs au réseau physique de l'hôte. Macvlan permet aux conteneurs de communiquer entre eux, tandis qu'ipvlan tend à les isoler davantage ; ces options sont utiles dans les déploiements où chaque conteneur doit être reconnu comme un hôte à part entière par le reste du réseau.

Réseaux sans racine : slirp4netns et pasta

Lorsque l'utilisateur n'est pas administrateur, les choses se compliquent : un utilisateur sans privilèges ne peut pas modifier librement l'espace de noms du réseau global ni créer d'interfaces arbitraires ; Podman doit donc recourir à des solutions en espace utilisateur pour assurer la connectivité.

C'est là qu'intervient slirp4netns , le mécanisme classique utilisé par Podman rootless . Ce projet crée un environnement réseau isolé au sein du conteneur et utilise le module slirp du noyau pour effectuer la traduction d'adresses (NAT) et permettre au conteneur d'accéder à Internet via le réseau de l'hôte.

En pratique, slirp4netns crée une interface TAP au sein de l'espace de noms réseau du conteneur (par exemple, tap0 avec l'adresse IP 10.0.2.100 et la passerelle 10.0.2.2) et achemine le trafic via une pile TCP/IP implémentée dans l'espace utilisateur. Cette solution est fonctionnelle, mais elle engendre une surcharge et certaines limitations.

L'une de ces limitations est que les utilisateurs non privilégiés ne peuvent pas utiliser les ports inférieurs à 1024. Le paramètre sysctl net.ipv4.ip_unprivileged_port_start indique à partir de quel port ils sont considérés comme « non privilégiés » (par défaut, 1024), bien que cela puisse être ajusté avec soin si le modèle de sécurité le permet.

Dans Podman 5, slirp4netns est remplacé par pasta comme mécanisme sans privilèges root par défaut . Pasta fonctionne également entièrement dans l'espace utilisateur, mais grâce à l'interface tap et aux techniques de zéro copie, il atteint des performances réseau quasi natives, réduisant ainsi l'impact sur la latence et le débit par rapport à slirp4netns.

Pont et réseaux hôtes dans des conteneurs sans privilèges.

Même en mode non root, il est possible de connecter des conteneurs sans privilèges root au réseau bridge « podman » par défaut grâce à l'option `--network=podman`. Ceci exploite les fonctionnalités de netavark et mappe les ports sur l'hôte avec l'option `-p`, comme en mode root.

Il est également possible de créer des réseaux pontés personnalisés dans des environnements sans privilèges root . Dans ce cas, les ponts et les périphériques associés ne sont pas créés dans l'espace de noms réseau global de l'hôte, mais dans l'espace de noms de l'utilisateur ; par conséquent, ces interfaces ne seront pas visibles depuis l'hôte avec une simple commande `sudo ip a`.

Pour examiner ces ponts réseau sans privilèges root, Podman propose la commande `podman unshare --rootless-netns` , qui ouvre un shell dans l'espace de noms réseau de l'utilisateur. À partir de là, les ponts internes peuvent être observés et la connectivité directe aux conteneurs peut être vérifiée.

Cet isolement a un effet curieux : Il se peut qu'il n'y ait pas de connectivité directe entre l'hôte et les adresses IP de ces conteneurs sans privilèges root.mais cela fonctionne avec les ports mappés sur l'adresse IP de l'hôte, qui servent de point d'entrée au service.
Pour la communication entre les conteneurs, le serveur DNS intégré au réseau pont défini par l'utilisateur leur permet de communiquer par leur nom, ce qui simplifie grandement la configuration des applications distribuées.

À l'autre extrémité se trouve le réseau hôte (--network=host) , où le conteneur partage la pile réseau avec l'hôte sans posséder sa propre adresse IP. Dans ce mode, si un conteneur sans privilèges root démarre un serveur sur le port 8080/tcp, le service sera directement accessible sur le port 8080 de l'hôte, ce qui évite le mappage de ports mais réduit l'isolation.

Podman Desktop, outils d'imagerie et orchestration locale

Pour ceux qui préfèrent une approche plus visuelle, Podman Desktop offre un environnement graphique pour la gestion des conteneurs, des pods, des images et des configurations réseau sur les machines de développement, constituant une alternative directe à Docker Desktop mais reposant sur un moteur sans démon.

Les images sont obtenues via la commande `podman pull`, qui les télécharge depuis les registres définis dans `/etc/containers/registries.conf` . Si l'image est spécifiée sans nom de registre, Podman tente de la localiser dans l'ordre des registres configuré, en utilisant par défaut l'étiquette `latest`.

Outre l'interface de ligne de commande Podman, nous pouvons utiliser skopeo comme outil dédié à la gestion, l'inspection et la copie d'images entre les registres et les dépôts locaux. Des commandes telles que copy, delete et sync permettent d'automatiser la synchronisation entre les dépôts, de marquer les images pour le nettoyage de la mémoire et de déplacer les artefacts entre les environnements.

Une fois l'image téléchargée, `podman run` permet de démarrer des conteneurs en spécifiant le transport et le chemin (par défaut, Docker et la recherche dans le registre configuré). Les options habituelles (-d, -p, --name, --pod, etc.) couvrent aussi bien les scénarios de laboratoire que les déploiements plus complexes.

La gestion quotidienne s'effectue avec `podman ps` pour lister les conteneurs, `podman stop/start` pour arrêter ou démarrer les instances existantes, et `podman rm` pour supprimer les conteneurs arrêtés . Si un conteneur a été modifié et que l'on souhaite le convertir en une nouvelle image, `podman commit` enregistre ces modifications sous un nouveau nom.

Pods et modèles d'exécution avancés avec Podman

Inspiré de Kubernetes, Podman permet de regrouper les conteneurs en pods qui partagent la même infrastructure réseau et certaines ressources . C'est un modèle idéal pour des applications comme une base de données et son client, ou plusieurs microservices nécessitant une communication à faible latence.

La commande `podman pod create` crée un nouveau pod et renvoie son ID, mais par défaut, le pod reste arrêté jusqu'à ce qu'un conteneur associé soit démarré ou qu'il soit explicitement lancé avec `podman pod start`.

Pour voir quels pods sont présents sur le système, utilisez la commande `podman pod ls` , qui affichera également le conteneur INFRA associé à chaque pod. Ce conteneur spécial assure le fonctionnement du réseau et des autres ressources partagées du pod ; par conséquent, le nombre de conteneurs n'est jamais nul.

Podman propose des commandes spécifiques pour démarrer, arrêter ou redémarrer des pods entiers (podman pod start/stop/restart) , mais nous pouvons également agir uniquement sur un conteneur spécifique au sein du pod sans modifier le reste, en maintenant l'isolation des processus au niveau de l'application.

Pour ajouter des conteneurs à un pod existant, utilisez la commande `podman run --pod NOM_DU_POD` , en respectant la même syntaxe que pour les conteneurs individuels. Il est impossible de retirer un conteneur d'un pod sans le détruire, car l'appartenance à un pod est liée à son cycle de vie.

La surveillance s'effectue à l'aide de la commande podman ps –pod ou de commandes spécifiques permettant de surveiller les processus de tous les conteneurs dans tous les pods , en identifiant rapidement ce qui appartient à quel groupe et comment les services sont distribués.

Conteneurs, LXC et virtualisation d'applications

Bien que Docker et Podman soient omniprésents, ils ne sont pas les seules options de conteneurisation sous GNU/Linux . Des solutions telles que LXC/LXD, systemd-nspawn et Kata Containers abordent le problème sous des angles légèrement différents.

LXC fournit des conteneurs système très légers, dotés de leur propre nom d'hôte, adresse IP, système de fichiers et système d'initialisation complet . Combiné à LXD, qui fait office d'hyperviseur pour les conteneurs et les machines virtuelles, il offre une expérience très proche de celle de plusieurs machines physiques légères aux performances quasi identiques à celles d'un système dédié.

Alors que Docker/Podman se concentrent sur les conteneurs d'applications compatibles OCI , LXC excelle lorsque des environnements persistants avec de multiples services et processus sont nécessaires, se comportant comme une machine virtuelle mais avec moins de surcharge et une intégration très naturelle avec le noyau Linux.

Du point de vue des performances, LXC peut exécuter des applications d'entreprise gourmandes en données sans pratiquement aucune pénalité , ce qui en fait un choix puissant pour les charges de travail sensibles à la latence qui ne nécessitent pas l'isolation forte d'une VM traditionnelle.

Parallèlement, les technologies axées sur les micro-VM et l'isolation renforcée ont également gagné du terrain, comme Kata Containers , qui lance chaque pod dans une petite machine virtuelle dotée de son propre noyau, ou gVisor, qui insère un « environnement isolé » (sandbox noyau) écrit en Go entre l'application et Linux. Ces deux technologies réduisent la dépendance au noyau partagé et se rapprochent du modèle de sécurité des VM tout en conservant la convivialité des conteneurs.

Meilleures pratiques pour renforcer la sécurité de Docker et Podman

Compte tenu de tout ce qui précède, l'approche raisonnable pour une plateforme de conteneurs robuste consiste à travailler par couches : segmentation avec espaces de noms/cgroups, politiques de filtrage avec seccomp et MAC, et restriction structurelle des privilèges via le mode sans racine.

En pratique, il est conseillé d'adopter la bonne pratique d' exécuter les conteneurs en mode non root chaque fois que cela est possible , notamment dans les environnements mutualisés ou au sein de clouds partagés. Podman facilite cette approche par défaut, et Docker rootless repose sur le même principe lorsque la compatibilité est requise.

Le noyau hôte doit être maintenu à jour avec les correctifs de sécurité . Les vulnérabilités telles que Dirty COW, Dirty Pipe et autres sont corrigées par des mises à jour qui doivent être appliquées rapidement si l'on veut éviter les évasions de conteneurs.

Une autre mesure très efficace consiste à utiliser des distributions immuables orientées conteneurs, telles qu'openSUSE MicroOS ou Flatcar Linux . Leur système de fichiers racine en lecture seule et leur système de mise à jour atomique réduisent considérablement la surface d'attaque et facilitent les restaurations en cas de problème après l'application d'un correctif.

Concernant la configuration : aucun conteneur privilégié n’est autorisé en production, sauf dans des cas extrêmement contrôlés ; il est déconseillé d’exécuter des applications en tant que root à l’intérieur d’un conteneur ; privilégiez les systèmes de fichiers en lecture seule et limitez les capacités au strict minimum. L’utilisation de profils SELinux/AppArmor et seccomp adaptés aux appels réels de l’application est quasiment indispensable.

Enfin, il ne faut pas négliger la surveillance en temps réel . Des outils comme Falco, Sysdig Secure ou Aqua permettent de détecter les anomalies, les tentatives d'évasion (telles que les accès inhabituels à /proc ou /sys), le trafic réseau atypique ou les commandes suspectes, offrant ainsi le temps de réagir avant que l'attaque ne prenne effet.

En combinant la virtualisation classique avec KVM, les conteneurs gérés par Podman (de préférence en mode sans privilèges root), des réseaux bien segmentés et des pratiques de sécurité robustes, il est possible de construire une plateforme de virtualisation très flexible et sécurisée. Comprendre que le noyau partagé est l'élément le plus critique, recourir aux machines virtuelles ou aux micro-machines virtuelles lorsque les risques ou la conformité réglementaire l'exigent, et gérer avec soin la chaîne d'approvisionnement des images font toute la différence entre un environnement de laboratoire et une infrastructure prête pour la production.