Docker dans un conteneur LXC sur Proxmox : une bonne idée ?

Un jour, en parcourant un forum sur Proxmox et Docker, je suis tombé sur un commentaire qui disait clairement :

It’s not recommended, since this is always a risk as it will expose /sys and /proc of your host with read-write permissions inside the container.

Ça m’a intrigué. J’utilise Proxmox dans mon homelab, et comme beaucoup, Docker est un incontournable pour mes services. Du coup, je me suis posé la question :

• Est-ce que Docker dans un conteneur LXC, c’est vraiment une mauvaise idée ?

Plutôt que de me contenter de cette affirmation, j’ai voulu creuser, tester, et voir ce qu’il en est réellement. Voici le résultat de mes recherches et de mes propres expérimentations.

Rappel des concepts

Avant d’aller plus loin, petit rappel rapide pour bien situer le sujet :

• Proxmox VE → une plateforme de virtualisation qui combine VM (via KVM) et conteneurs système (via LXC).
• LXC → des conteneurs qui partagent le noyau de l’hôte, plus légers qu’une VM mais moins isolés.
• Docker → des conteneurs applicatifs, parfaits pour déployer rapidement des services.

Mettre Docker dans un LXC, c’est donc imbriquer deux couches de conteneurisation sur un même noyau.

Mes découvertes et limites

En testant Docker dans différents LXC, j’ai repéré plusieurs points problématiques :

• Mode privilégié vs non privilégié

  • Non privilégié : le root interne est mappé vers un utilisateur non-root de l’hôte → plus sûr, mais Docker peux parfois ne pas fonctionner avec certaines images : erreurs de cgroups, permissions insuffisantes, limitations sur certaines opérations réseau ou système.
  • Privilégié : Docker fonctionne parfaitement, mais le conteneur obtient quasi tous les privilèges du noyau hôte. Concrètement, un conteneur compromis peut toucher l’ensemble du système Proxmox.

• Configuration et compatibilité
  Pour que Docker tourne, il faut souvent activer nesting et keyctl, et parfois ajouter des périphériques comme /dev/net/tun. C’est faisable mais ça élargit la surface d’attaque.

• Complexité et maintenance
  La combinaison LXC + Docker ajoute une couche de complexité : il faut maintenir à jour Docker, LXC et le noyau de Proxmox pour rester sécurisé. Une mauvaise configuration des profils de sécurité (AppArmor, SELinux) peut annuler tous les bénéfices.

Sécurité et risques

1. Isolation du noyau

Un conteneur LXC partage le noyau Linux de l’hôte, contrairement à une VM qui possède son propre noyau isolé. Cela signifie que toute faille exploitée dans un conteneur peut potentiellement affecter l’hôte.

Deux mécanismes clés assurent l’isolation :

• Namespaces : ils isolent les processus, le réseau, les utilisateurs et le filesystem. Chaque conteneur voit son propre environnement (PID, réseau, filesystem), mais il partage toujours le même noyau que l’hôte.

  Exemple : un processus a PID 1 dans le conteneur, mais ce n’est pas PID 1 sur l’hôte.

• Cgroups (control groups) : ils limitent et surveillent l’usage des ressources (CPU, RAM, I/O) par un conteneur, empêchant un conteneur de saturer l’hôte.

Exposer les cgroups de l’hôte au conteneur LXC (souvent nécessaire pour que Docker fonctionne correctement) a plusieurs implications importantes :

1. Le conteneur peut voir et potentiellement manipuler les limites et usages des autres conteneurs ou de l’hôte.
2. Il peut contourner certaines limites de ressources ou interférer avec le reste du système.
3. Cela augmente considérablement la surface d’attaque : un conteneur compromis peut exploiter ces accès pour toucher d’autres conteneurs ou le noyau de l’hôte.

En pratique, cela explique pourquoi Docker fonctionne mieux en LXC privilégié : le conteneur a tous les accès nécessaires pour gérer ses cgroups et ses namespaces.
Mais c’est aussi ce qui rend ce mode beaucoup plus dangereux côté sécurité : un conteneur compromis peut accéder directement à des fonctionnalités critiques du noyau et impacter l’hôte.

2. Failles documentées (CVE)

Plusieurs vulnérabilités montrent que l’évasion de conteneur est possible, même sans configuration privilégiée :

Ces exemples montrent que même un conteneur non privilégié n’est pas invulnérable, et que le noyau reste le point critique.

3. Surface d’attaque et complexité

• Empiler LXC + Docker ajoute de la complexité. Chaque couche a ses propres configurations, cgroups, namespaces et profils de sécurité.
• La maintenance devient plus compliquée : mettre à jour Docker, LXC et le noyau de l’hôte simultanément est nécessaire pour rester protégé.
• Les erreurs de configuration (capabilities, périphériques exposés, nesting) augmentent fortement le risque.

En résumé, ce qui rend Docker dans LXC “mauvais côté sécurité”, ce n’est pas seulement Docker ou LXC individuellement, mais l’interaction complexe entre les deux et le partage du noyau Linux.

Alternatives plus sûres

• Docker dans une VM dédiée : un peu plus de ressources consommées, mais isolation bien plus robuste.
• Podman rootless dans un LXC non privilégié : plus complexe à configurer, mais intéressant car il ne tourne pas en root.
• Directement LXC sans Docker : pour certains services (ex. serveur web simple, base de données), un LXC bien configuré suffit largement et consomme tout aussi peu de ressources qu’un contenur Docker.

Mon avis final

Dans mon homelab, Docker dans LXC fonctionne et c’est pratique pour expérimenter. Mais si je devais exposer un service ou héberger quelque chose d’important :

• je passerais par une VM dédiée avec mes conteneurs dockers dedans,
• ou j’envisagerais Podman rootless pour éviter le démon Docker root.

C’est donc surtout un compromis entre simplicité, performances et sécurité.