LXC est le runtime de conteneur Linux de bas niveau bien connu et fortement testé. Il est en développement actif depuis 2008 et a fait ses preuves dans des environnements de production critiques du monde entier. Certains de ses principaux contributeurs sont les mêmes personnes qui ont aidé à implémenter diverses fonctionnalités de conteneurisation bien connues au sein du noyau Linux.
Taper | Service | Statut |
---|---|---|
CI (Linux) | GitHub | |
CI (Linux) | Jenkins | |
Statut du projet | Meilleures pratiques CII | |
Fuzzing | OSS-Fuzz | |
Fuzzing | CIFuzz |
L'objectif principal de LXC est les conteneurs système. C'est-à-dire des conteneurs qui offrent un environnement aussi proche que possible de celui que vous obtiendriez d'une VM, mais sans la surcharge liée à l'exécution d'un noyau séparé et à la simulation de tout le matériel.
Ceci est réalisé grâce à une combinaison de fonctionnalités de sécurité du noyau telles que les espaces de noms, le contrôle d'accès obligatoire et les groupes de contrôle.
Les conteneurs sans privilèges sont des conteneurs exécutés sans aucun privilège. Cela nécessite la prise en charge des espaces de noms utilisateur dans le noyau sur lequel le conteneur est exécuté. LXC a été le premier moteur d'exécution à prendre en charge les conteneurs non privilégiés après la fusion des espaces de noms d'utilisateurs dans le noyau principal.
Essentiellement, les espaces de noms utilisateur isolent des ensembles donnés d’UID et de GID. Ceci est réalisé en établissant un mappage entre une plage d'UID et de GID sur l'hôte vers une plage différente (non privilégiée) d'UID et de GID dans le conteneur. Le noyau traduira ce mappage de telle manière qu'à l'intérieur du conteneur, tous les UID et GID apparaissent comme vous pouvez l'attendre de l'hôte alors que sur l'hôte, ces UID et GID ne sont en fait pas privilégiés. Par exemple, un processus exécuté sous l'UID et le GID 0 à l'intérieur du conteneur peut apparaître sous l'UID et le GID 100 000 sur l'hôte. Les détails d'implémentation et de fonctionnement peuvent être rassemblés à partir de la page de manuel de l'espace de noms utilisateur correspondant.
Étant donné que les conteneurs sans privilèges constituent une amélioration de la sécurité, ils sont naturellement accompagnés de quelques restrictions appliquées par le noyau. Afin de fournir un conteneur non privilégié entièrement fonctionnel, LXC interagit avec 3 morceaux de code setuid :
Tout le reste est exécuté en tant que votre propre utilisateur ou en tant qu'uid appartenant à votre utilisateur.
En général, l'objectif de LXC est d'utiliser toutes les fonctionnalités de sécurité disponibles dans le noyau. Cela signifie que la gestion de la configuration de LXC permettra aux utilisateurs expérimentés d'ajuster de manière complexe LXC à leurs besoins.
Une introduction plus détaillée à la sécurité LXC peut être trouvée sous le lien suivant
En principe, LXC peut être exécuté sans aucun de ces outils à condition que la configuration correcte soit appliquée. Cependant, l’utilité de tels conteneurs est généralement assez limitée. Juste pour souligner les deux problèmes les plus courants :
Réseau : sans compter sur un assistant setuid pour configurer les périphériques réseau appropriés pour un utilisateur non privilégié (voir le binaire lxc-user-nic
de LXC), la seule option est de partager l'espace de noms réseau avec l'hôte. Même si cela devrait être sécurisé en principe, le partage de l'espace de noms réseau de l'hôte représente toujours une étape d'isolation en moins et augmente le vecteur d'attaque. De plus, lorsque l'hôte et le conteneur partagent le même espace de noms réseau, le noyau refusera tout montage sysfs. Cela signifie généralement que le binaire d'initialisation à l'intérieur du conteneur ne pourra pas démarrer correctement.
Espaces de noms d'utilisateur : comme indiqué ci-dessus, les espaces de noms d'utilisateur constituent une amélioration majeure en matière de sécurité. Cependant, sans recourir à des assistants privilégiés, les utilisateurs non privilégiés sur l'hôte sont uniquement autorisés à mapper leur propre UID dans un conteneur. Cependant, un système POSIX standard nécessite que 65 536 UID et GID soient disponibles pour garantir une fonctionnalité complète.
LXC est configuré via un simple jeu de clés. Par exemple,
lxc.rootfs.path
lxc.mount.entry
Clés de configuration des espaces de noms LXC à l’aide de points simples. Cela signifie que des clés de configuration complexes telles que lxc.net.0
exposent diverses sous-clés telles que lxc.net.0.type
, lxc.net.0.link
, lxc.net.0.ipv6.address
et d'autres pour encore plus de précision. configuration granuleuse.
LXC est utilisé comme moteur d'exécution par défaut pour Incus, un hyperviseur de conteneur exposant par-dessus une API REST bien conçue et stable.
LXC fonctionne sur n'importe quel noyau à partir de la version 2.6.32. Tout ce qu'il faut, c'est un compilateur C fonctionnel. LXC fonctionne sur toutes les architectures fournissant les fonctionnalités de noyau nécessaires. Cela comprend (mais sans s'y limiter) :
LXC prend également en charge au moins les bibliothèques standard C suivantes :
LXC s'est toujours concentré sur une forte compatibilité ascendante. En fait, l'API n'a pas été interrompue depuis la version 1.0.0
. Main LXC est actuellement en version 4.*.*
.
Le projet LXC a une bonne réputation dans la gestion rapide et efficace des problèmes de sécurité. Si vous pensez avoir découvert un problème de sécurité potentiel, veuillez le signaler par e-mail à security (at) linuxcontainers (dot) org.
Pour plus de détails, veuillez consulter
Nous accueillons toujours de nouveaux contributeurs et sommes heureux de vous fournir des conseils si nécessaire. LXC suit les conventions de codage du noyau. Cela signifie que nous exigeons uniquement que chaque validation comprenne une ligne Signed-off-by
. Le style de codage que nous utilisons est identique à celui utilisé par le noyau Linux. Vous pouvez trouver une introduction détaillée à l’adresse suivante :
et devrait également jeter un œil au fichier CONTRIBUTING dans ce dépôt.
Si vous souhaitez devenir plus actif, c'est généralement aussi une bonne idée de vous présenter sur le canal IRC LXC #lxc-dev sur irc.libera.chat. Nous essayons de réaliser tout le développement à l'air libre et la discussion des nouvelles fonctionnalités ou des bugs se fait soit dans les numéros GitHub appropriés, soit sur IRC.
Lorsque vous envisagez d'apporter des contributions critiques en matière de sécurité ou des changements substantiels, il est généralement judicieux d'envoyer d'abord une requête ping aux développeurs et de leur demander si un PR serait accepté.
LXC et ses projets associés adhèrent strictement à un schéma de version sémantique.
La source de la dernière version publiée peut toujours être téléchargée à partir de
Vous pouvez parcourir le code source à la minute près et modifier l'historique en ligne.
Sans considérer les détails spécifiques à la distribution, un simple
meson setup -Dprefix=/usr build
meson compile -C build
est généralement suffisant.
Lorsque vous avez besoin d'aide, les projets LXC vous proposent plusieurs options.
Nous maintenons un forum de discussion à
où vous pouvez obtenir de l'aide.
Vous pouvez nous trouver en #lxc sur irc.libera.chat.
Vous pouvez consulter l'une des deux archives de la liste de diffusion LXC et vous inscrire si vous êtes intéressé :