Linux LXC vs prison FreeBSD

Existe-t-il des différences notables entre les conteneurs LXC (conteneurs Linux) et les jails FreeBSD en termes de sécurité, de stabilité et de performances?

À première vue, les deux approches sont très similaires.

Peu importe le nom sophistiqué utilisé ici, les deux solutions à un problème spécifique: une meilleure solution de ségrégation que le chroot Unix classique . La virtualisation au niveau du système d'exploitation, les conteneurs, les zones ou même "chroot avec des stéroïdes" sont des noms ou des titres commerciaux qui définissent le même concept de séparation de l'espace utilisateur, mais avec des fonctionnalités différentes.

Chroot a été introduit le 18 mars 1982, quelques mois avant la sortie de la version 4.2 BSD , comme outil pour tester son système d'installation et de construction, mais il a encore ses défauts aujourd'hui. Comme le premier objectif de chroot était uniquement de fournir un nouveau chemin de racine , d'autres aspects du système qui devaient être isolés ou contrôlés ont été découverts (réseau, vue de processus, débit d'E / S). C’est là que les premiers conteneurs (virtualisation au niveau utilisateur) sont apparus.

Les deux technologies (JBS FreeBSD et LXC) utilisent l’isolation de l’espace utilisateur pour fournir une couche de sécurité supplémentaire. Cette compartimentation garantit qu'un processus déterminé communiquera uniquement avec les autres processus du même conteneur sur le même hôte. Si vous utilisez une ressource réseau pour établir une communication "en dehors du monde", tous seront transférés vers l'interface / le canal attribué à ce conteneur. a.

Caractéristiques

JBS FreeBSD:

• Considéré comme une technologie stable, car c’est une fonctionnalité de FreeBSD depuis la 4.0;
• Il faut le meilleur du système de fichiers ZFS au moment où vous pouvez cloner des jails et créer des modèles de jail pour déployer facilement plus de jails. Un peu plus de folie ZFS ;
• Bien documenté et évolutif ;
• Les prisons hiérarchiques vous permettent de créer des prisons à l'intérieur d'une prison (il faut aller plus loin!). Combinez avec allow.mount.zfspour obtenir plus de puissance, et d'autres variables telles que children.maxne définissent pas le maximum de prisons pour enfants.
• rctl (8) gérera les limites de ressources des jails (mémoire, CPU, disque, ...);
• Les jails FreeBSD gèrent l’ espace utilisateur Linux ;
• Isolement du réseau avec vnet, permettant à chaque prison d’avoir sa propre pile réseau, ses interfaces, ses tables d’adressage et de routage;
• nullfs pour aider à relier des dossiers à ceux qui sont situés sur le serveur réel à l'intérieur d'une prison;
• ezjail pour aider les déploiements de masse et la gestion des prisons;
• Beaucoup de paramètres de noyau ( sysctl). security.jail.allow.*Les paramètres limiteront les actions de l'utilisateur root de cette prison.
• Peut-être que les prisons FreeBSD étendront dans un proche avenir certaines fonctionnalités du projet VPS, telles que la migration en direct .
• Certains efforts d’ intégration de ZFS et de Docker sont en cours d’exécution. Encore expérimental.
• FreeBSD 12 prend en charge bhyve à l'intérieur d'une prison et pf à l'intérieur d'une prison, créant ainsi une isolation supplémentaire pour ces outils
• Beaucoup d'outils intéressants ont été développés au cours des dernières années. Certains d'entre eux sont indexés sur ce blog .
• Alternatives: projet VPS FreeBSD

Conteneurs Linux (LXC):

• Nouvelle technologie "dans le noyau" mais approuvée par de grandes technologies (spécialement Canonical);
• Les conteneurs non privilégiés, à partir de LXC 1.0, constituent une étape importante dans la sécurité des conteneurs;
• Mappage UID et GID à l'intérieur des conteneurs;
• Les espaces de noms de noyau, pour séparer IPC, mount, pid, réseau et utilisateurs. Ces espaces de noms peuvent être gérés de manière séparée, lorsqu'un processus utilisant un espace de noms de réseau différent ne sera pas nécessairement isolé sur d'autres aspects tels que le stockage;
• Groupes de contrôle (cgroups) pour gérer les ressources et les regrouper. CGManager est le gars pour y parvenir.
• Profils Apparmor / SELinux et fonctionnalités du noyau pour une meilleure application des fonctionnalités du noyau accessibles par les conteneurs. Seccomp est également disponible sur les conteneurs lxc pour filtrer les appels système. Autres aspects de sécurité ici .
• Fonctionnalité de migration en cours de développement. Il est vraiment difficile de dire quand il sera prêt à l' emploi de la production, puisque docker / lxc devra traiter avec le processus de pause userspace, instantané, migrer et consolider - ref1 , ref2 .La migration en direct fonctionne avec des conteneurs de base (aucun périphérique ne diffère, pas plus que des services réseau complexes ou des configurations de stockage spéciales).
• Liaisons d'API pour permettre le développement dans python3 et 2, lua, go, ruby ​​et haskell
• Zone centralisée "Quoi de neuf". Très utile lorsque vous devez vérifier si un bogue a été corrigé ou si une nouvelle fonctionnalité a été validée. Ici .
• Une alternative intéressante pourrait être LXD , qui sous le capot fonctionne avec LXC mais, il a quelques fonctionnalités intéressantes comme une API REST, une intégration OpenStack, etc.
• Une autre chose intéressante est qu'Ubuntu semble envoyer zfs en tant que système de fichiers par défaut pour les conteneurs le 16.04 . Pour garder les projets alignés, lxd a lancé sa version 2.0, et certaines fonctionnalités sont liées à zfs .
• Alternatives : OpenVZ , Docker
• Docker . Notez ici que Docker utilise des espaces de noms, cgroups créant une isolation "par application" / "par logiciel". Principales différences ici . Tandis que LXC crée des conteneurs avec plusieurs processus, Docker réduit le plus possible un conteneur à un seul processus, puis le gère via Docker.
• Effort d'intégration de Docker avec SELinux et réduction des capacités à l'intérieur d'un conteneur pour le rendre plus sécurisé - Docker et SELinux, Dan Walsh
• Quelle est la différence entre Docker, LXD et LXC

Docker n'utilise plus lxc. Ils ont maintenant une bibliothèque spécifique appelée libcontainer qui gère directement l'intégration avec les espaces de noms de noyau de bas niveau et les fonctionnalités de groupe de contrôle.

Aucune de ces technologies n’est une panacée en matière de sécurité, mais les deux constituent de très bons moyens pour isoler un environnement qui n’exige pas de virtualisation complète en raison d’une infrastructure de systèmes d’exploitation mixte. La sécurité viendra après de nombreuses lectures de documentation et la mise en œuvre des paramètres ajustables du noyau, des codes MAC et des isolations que ces systèmes virtuels vous offrent.

Voir également:

• Contenants artisanaux
• BSD Now: Tout ce que vous devez savoir sur les prisons
• ezjail - cadre d'administration de la prison
• Une brève histoire des conteneurs: des années 1970 à 2017
• Docker Considered Harmful - Bon article sur le cirque de sécurité autour des technologies de conteneur.