Limites de sécurité de Docker par rapport à LXC pour les services domestiques privilégiés

Docker est le choix par défaut le plus sûr lorsqu'un service domestique privilégié peut rester une seule application déclarée avec des montages limités. LXC est plus propre lorsqu'il a réellement besoin d'un petit système Linux, mais aucun des deux ne crée une limite distincte au niveau du noyau.

La question décisive n'est pas de savoir quelle étiquette semble la plus isolée. Les deux reposent sur un confinement assuré par le noyau hôte. Comparez les privilèges réellement accordés, les périphériques et fichiers exposés, l'unité que vous corrigez et restaurez, ainsi que les conséquences d'une évasion. Si l'exposition à un noyau partagé elle-même est inacceptable, cessez de comparer Docker et LXC et utilisez une VM ou un hôte séparé.

Acceptez la limite du noyau partagé avant de comparer les fonctionnalités

Docker regroupe normalement une application et ses dépendances ; LXC fournit un espace utilisateur Linux plus complet avec init, comptes, paquets et services système. Cette différence opérationnelle ne donne pas à LXC un noyau invité indépendant.

Les recherches sur le confinement des conteneurs Linux décrivent les mécanismes d'espaces de noms et de politiques comme un ensemble disparate dont la sémantique peut être difficile à auditer. Cette limite du confinement assuré par un noyau partagé s'applique aux deux candidats et empêche l'un ou l'autre de constituer la solution lorsque la séparation du noyau est obligatoire.

Ne retenez les deux options que pour des charges de travail fiables ou limitées. Déplacez le code exposé à Internet, les images inconnues ou l'automatisation à conséquences importantes vers une VM lorsqu'une compromission ne doit pas atteindre directement le noyau hôte.

Laissez le privilège requis modifier le choix par défaut

Docker reste intéressant lorsque le service a besoin de quelques capacités explicites, d'une configuration en lecture seule et d'un ou deux chemins persistants. Sa définition Compose peut rendre ces exceptions visibles lors de la revue.

LXC convient aux services qui attendent un système Linux conventionnel, plusieurs démons, un gestionnaire de paquets ou une mise en réseau stable au niveau du système. LXC non privilégié conserve une correspondance d'UID utile, mais le mode privilégié, l'imbrication et les montages liés étendus réduisent cet avantage.

Comptez les exceptions plutôt que de cocher une case de privilège. Si l'une ou l'autre conception nécessite le réseau de l'hôte, le socket de gestion des conteneurs, des montages système accessibles en écriture, tous les périphériques ou un profil non confiné, repensez le chemin d'accès ou quittez le niveau du noyau partagé.

L'accès aux périphériques et au stockage détermine l'ampleur des dommages

Un contrôleur USB, un nœud de rendu GPU, une interface UPS ou un répertoire multimédia doit être exposé aussi strictement que le service le permet. Des chemins de périphériques stables, des montages en lecture seule et une propriété UID/GID explicite sont des contrôles de confinement autant que des réglages pratiques.

Un compte rendu récent d'un déploiement Proxmox montre que LXC non privilégié peut isoler des services reposant sur Docker dans des unités de restauration distinctes tout en partageant le noyau hôte et la pile de stockage. Ce modèle LXC à faible rayon d'action n'est utile que lorsque l'imbrication et les exceptions liées au pilote de stockage restent documentées.

Préférez Docker lorsqu'une application a besoin d'une seule petite limite de données. Préférez LXC lorsque plusieurs services système doivent rester regroupés. Rejetez l'une ou l'autre organisation si une seule compromission donne un accès en écriture aux sauvegardes, au contrôle de l'hyperviseur ou aux données familiales sans rapport.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Comparez l'unité que vous corrigez et restaurez

Avec Docker, revenir en arrière signifie normalement restaurer la révision Compose et l'image précédentes, ainsi que des données cohérentes avec l'application. Avec LXC, revenir en arrière peut restaurer un espace utilisateur entier, ce qui est pratique, mais peut aussi réintroduire des paquets obsolètes, des identifiants et des modifications manuelles cachées.

Reconstruisez chaque candidat sur un hôte jetable. Pour Docker, restaurez les définitions, les secrets et les volumes ; pour LXC, recréez ou restaurez le conteneur et vérifiez l'état des paquets, du réseau, des périphériques et des montages. Un test réussi plus facile constitue un indice plus probant qu'une consommation mémoire au repos plus faible.

La décision plus large de ZimaSpace concernant les limites de service VM, LXC et Docker est l'étape suivante lorsqu'un noyau indépendant reste envisagé.

Verdict conditionnel : choisissez la limite la plus étroite qui contient malgré tout la défaillance

Choisissez Docker pour une application fiable, bien empaquetée, dont les périphériques, capacités, secrets et chemins persistants peuvent rester explicites et minimaux.

Choisissez LXC pour un environnement de services Linux fiable qui bénéficie réellement d'init, de paquets, de plusieurs démons ou d'une mise en réseau au niveau du système, tout en restant non privilégié autant que possible.

Ne choisissez ni l'un ni l'autre lorsque la charge de travail nécessite un contrôle étendu de l'hôte, traite des entrées hostiles à conséquences importantes ou doit résister à une compromission du noyau hôte. À ce stade, une VM ou une machine séparée n'est pas du surdimensionnement ; c'est la limite de sécurité manquante.