Limites de sécurité entre Docker et 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 application déclarée unique 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 frontière séparée entre les noyaux.

La question décisive n’est pas de savoir quelle étiquette semble la plus isolante. Les deux reposent sur le confinement par le noyau de l’hôte. Comparez les privilèges réellement accordés, les appareils 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é est en soi inacceptable, cessez de comparer Docker et LXC et utilisez une VM ou un hôte distinct.

Acceptez les limites du noyau partagé avant de comparer les fonctionnalités

Docker regroupe généralement une application et ses dépendances ; LXC fournit un espace utilisateur Linux plus complet, avec init, des comptes, des paquets et des services système. Cette différence opérationnelle ne confère 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 assemblage hétéroclite dont la sémantique peut être difficile à auditer. Cette limite du confinement par noyau partagé s’applique aux deux options et empêche l’une comme l’autre de convenir lorsque la séparation des noyaux est obligatoire.

Ne retenez les deux options que pour les charges de travail fiables ou limitées. Transférez le code exposé à Internet, les images inconnues ou l’automatisation à haut risque dans une VM lorsque toute compromission ne doit pas pouvoir atteindre directement le noyau de l’hôte.

Laissez le niveau de privilèges requis guider le choix par défaut

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

LXC convient aux services qui attendent un système Linux classique, plusieurs démons, un gestionnaire de paquets ou une configuration réseau stable au niveau du système. LXC non privilégié préserve un mappage des UID utile, mais le mode privilégié, l’imbrication et les montages liés étendus en réduisent les avantages.

Comptez les exceptions au lieu de cocher une case indiquant des privilèges élevés. 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 appareils ou un profil sans restrictions, repensez le chemin d’accès ou quittez la catégorie des noyaux partagés.

L’accès aux appareils et au stockage détermine l’ampleur des dégâts

Une interface de coordination USB, un nœud de rendu GPU, une interface d’onduleur ou un répertoire multimédia ne doivent être exposés que dans la mesure nécessaire au service. Des chemins de périphériques stables, des montages en lecture seule et une attribution explicite des UID/GID sont des mesures de cloisonnement autant que des paramètres pratiques.

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

Préférez Docker lorsqu’une application a besoin d’une seule petite frontière de données. Préférez LXC lorsque plusieurs services système doivent fonctionner ensemble. Rejetez l’une ou l’autre configuration si une compromission donne un accès en écriture aux sauvegardes, au contrôle de l’hyperviseur ou aux données d’autres membres de la famille.

Featured

ZimaBoard 2 - Mini-serveur domestique pour vos grandes idées

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Comparez l’unité que vous mettez à jour et restaurez

En général, revenir en arrière avec Docker consiste à restaurer la révision précédente de Compose et l’image correspondante, ainsi que des données cohérentes avec l’application. Avec LXC, il est possible de restaurer tout un environnement utilisateur, ce qui est pratique, mais peut aussi réintroduire des paquets obsolètes, des identifiants et des modifications manuelles cachées.

Recréez chaque option 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 concluant et plus facile à effectuer constitue une preuve plus solide qu’une consommation mémoire inférieure au repos.

Pour aller plus loin dans le choix entre les frontières de service VM, LXC et Docker, l’étape suivante consiste à déterminer si un noyau indépendant reste nécessaire.

Verdict conditionnel : choisissez la frontière la plus étroite qui contient malgré tout les défaillances

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

Choisissez LXC pour un environnement de service Linux de confiance qui tire réellement parti d’un système d’initialisation, de paquets, de plusieurs démons ou d’une configuration réseau au niveau du système, tout en restant non privilégié dans la mesure du 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 malveillantes susceptibles d’avoir de graves conséquences ou doit résister à la compromission du noyau de l’hôte. Dans ce cas, une machine virtuelle ou une machine distincte n’est pas une complication inutile : c’est la frontière de sécurité qui manque.