web-dev-qa-db-fra.com

Linux LXC vs prison FreeBSD

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

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

linuxfreebsdvirtualizationlxcjails
67
Philipp Claßen

Peu importe le nom de fantaisie utilisé ici, les deux sont des solutions à un problème spécifique: Une meilleure solution de ségrégation que Unix classique chroot . La virtualisation au niveau du système d'exploitation, les conteneurs, les zones ou même "chroot with steroids" 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 4.2 BSD , comme un outil pour tester son système d'installation et de construction, mais aujourd'hui il a encore ses défauts. Étant donné que le premier objectif de chroot était uniquement de fournir un chemin newroot, 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 de niveau utilisateur) sont apparus.

Les deux technologies (FreeBSD Jails et LXC) utilisent l'isolement de l'espace utilisateur pour fournir une autre couche de sécurité. Cette compartimentation garantira qu'un processus déterminé ne communiquera qu'avec d'autres processus dans le même conteneur sur le même hôte, et si vous utilisez une ressource réseau pour réaliser une communication "hors du monde", tout sera transmis à l'interface/au canal assigné que ce conteneur a.

Caractéristiques

Prisons FreeBSD:

  • Considéré comme une technologie stable, car c'est une fonctionnalité à l'intérieur de FreeBSD depuis 4.0;
  • Il prend le meilleur du système de fichiers ZFS au point où vous pouvez cloner des prisons et créer modèles de prison pour déployer facilement plus de prisons. Un peu plus folie ZFS ;
  • bien documenté , et évolutif ;
  • Les prisons hiérarchiques vous permettent de créer des prisons à l'intérieur d'une prison (nous devons aller plus loin!). Combiner avec allow.mount.zfs pour obtenir plus de puissance, et d'autres variables comme children.max définissez le nombre maximal de prisons pour enfants.
  • rctl (8) gérera les limites de ressources des prisons (mémoire, CPU, disque, ...);
  • Les prisons FreeBSD gèrent Linux espace utilisateur ;
  • 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 à lier des dossiers à ceux qui sont situés sur le vrai serveur à l'intérieur d'une prison;
  • ezjail utilitaire pour aider les déploiements de masse et la gestion des prisons;
  • Beaucoup de réglages du 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 certaines des fonctionnalités du projet VPS comme migration en direct dans un avenir proche.
  • Il y a un certain effort de ZFS et Docker intégration en cours d'exécution. Toujours expérimental.
  • FreeBSD 12 prend en charge bhyve à l'intérieur d'une prison et pf à l'intérieur d'une prison, créant une isolation supplémentaire de ces outils
  • De nombreux outils intéressants ont été développés au cours des dernières années. Certains d'entre eux sont indexés sur ce billet de blog .
  • Alternatives: projet FreeBSD VPS

Conteneurs Linux (LXC):

  • Nouvelle technologie "dans le noyau" mais approuvée par les plus grandes (spécialement canoniques);
  • Conteneurs non privilégiés à partir de LXC 1.0, fait un grand pas vers la sécurité à l'intérieur des conteneurs;
  • Mappage UID et GID à l'intérieur des conteneurs;
  • Espaces de noms du noyau, pour séparer IPC, mount, pid, réseau et utilisateurs. Ces espaces de noms peuvent être gérés de manière détachée, où un processus qui utilise un espace de noms de réseau différent ne sera pas nécessairement isolé sur d'autres aspects comme 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 capacité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 direct en cours de développement. Il est vraiment difficile de dire quand il sera prêt pour une utilisation en production, car docker/lxc devra gérer la pause, l'instantané, la migration et la consolidation du processus de l'espace utilisateur - ref1 , ref2 . Migration en direct fonctionne avec des conteneurs de base (pas de relais de périphérique ni de services réseau complexes ou de configurations de stockage spéciales).
  • Liaisons d'API pour permettre le développement en python3 et 2, lua, Go, Ruby et Haskell
  • Zone "Quoi de neuf" centralisée. 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 un REST api, intégration OpenStack, etc.
  • Une autre chose intéressante est qu'Ubuntu semble expédier zfs comme système de fichiers par défaut pour les conteneurs sur 16.04 . Pour garder les projets alignés, lxd a lancé sa version 2.0, et certaines des fonctionnalités sont liées à zfs .
  • Alternatives : OpenVZ , Docker
  • Docker . Notez ici que Docker utilise des espaces de noms, des groupes de contrôle créant une isolation "par application"/"par logiciel". Différences clés ici . Alors que LXC crée des conteneurs avec plusieurs processus, Docker réduit autant que possible un conteneur à un seul processus, puis gère cela via Docker.
  • Effort d'intégration de Docker avec SELinux et de 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 runc qui gère directement l'intégration avec l'espace de noms du noyau de bas niveau et les fonctionnalités de cgroups.

Aucune de ces technologies n'est une panacée en matière de sécurité, mais les deux sont de très bons moyens d'isoler un environnement qui ne nécessite pas de virtualisation complète en raison d'une infrastructure de systèmes d'exploitation mixtes. La sécurité viendra après de nombreuses lectures de documentation et implémentations de réglages du noyau, MAC et isolations que ces virtuos de niveau OS vous offrent.

Voir aussi:

108
user34720