Cette page permet de comprendre le concept de conteneur.
Pour comprendre je vous propose d'exécuter ce script qui permet de lister les namespaces dans lesquels chaque processus d'un système vit.
Sur une machine qui contient des conteneurs gérés par Proxmox ça donne ça :
# ./list-namespaces -H
USER PPID CGROUP IPC MNT NET PID PID_FOR_CHILDREN USER UTS COMMAND
root 0 I_cgroup I_ipc I_mnt netA I_pid I_pid I_user I_uts kthreadd
[...]
root 1 I_cgroup I_ipc mntC netA I_pid I_pid I_user I_uts systemd-udevd
[...]
root 1 I_cgroup I_ipc I_mnt netA I_pid I_pid I_user I_uts kvm
root 1 I_cgroup I_ipc mntF netA I_pid I_pid I_user I_uts lxc-start
100000 3190 cgroupB ipcB mntG netB pidB pidB userB utsB systemd
100000 3801 cgroupB ipcB mntG netB pidB pidB userB utsB nscd
121005 3801 cgroupB ipcB mntG netB pidB pidB userB utsB systemd
[...]
root 1 I_cgroup I_ipc mntO netA I_pid I_pid I_user I_uts lxc-start
100000 4449 cgroupE ipcE mntP netD pidE pidE userE utsE init
100000 4553 cgroupE ipcE mntP netD pidE pidE userE utsE apache2
100033 5757 cgroupE ipcE mntP netD pidE pidE userE utsE apache2
[...]
Ce que l'on voit :
kvm ;lxc-start.Donc alors qu'une machine virtuelle est une machine complète en elle-même, un conteneur exécute ses processus comme si c'était son parent. Un conteneur ne contient pas de noyau et souvent est beaucoup plus léger qu'une machine virtuelle pour cette raison.
Si quelqu'un pirate le conteneur qu'est-ce qu'il se passe ?
Vous remarquez les colonnes CGROUP, IPC, MNT, NET… sur le tableau ci-dessus. En faite ce sont des namespaces noyau. Certes le conteneur tourne avec le noyau de l'hôte mais n'a accès qu'à une partie restreinte.
Un conteneur ne peut pas remonter au parent et c'est ce qui en fait son intérêt. Ça permet alors d'isoler des environnements entier avec des versions différentes de programmes, pouvoir exécuter des programmes auxquels on n'a pas confiance sans pour autant mettre en danger l'hôte.
Est-ce vraiment vrai ? Malheureusement certaines failles de sécurité du noyau Linux permettent de remonter et d'attaquer l'hôte.
Le concept est que l'utilisateur root du conteneur est mappé différemment que celui de l'hôte : sur le tableau en haut on voit que lxc-start est exécuté par root, mais systemd est exécuté par l'utilisateur root interne au conteneur d'UID 100000.
Je vous invite à lire https://linuxcontainers.org/lxc/security/.
Les conteneurs non privilégiés ont le désavantage de ne pas permettre certaines tâches. Par exemple il est impossible de lancer Wine car Wine ne pourra pas faire ses accès mémoire.
Ce qu'il faut retenir c'est que si on peut faire du non privilégié alors on le fait car ça apporte une couche de sécurité en plus. Si on ne peut pas, bah c'est le moment de se poser la question si une machine virtuelle n'est pas mieux adapté.
Alors les points de vu sont très variés.
Certain·e·s prônent les architectures avec que des micro-services isolés dans des conteneurs, ce que fait Docker et surtout docker-compose. L'avantage c'est d'être entièrement indépendant, de pouvoir faire tourner plusieurs instances sur des serveurs distincts (voir Docker Swarm). C'est une philosophie que l'on ne suit pas à Aurore.
Le principal désavantage des conteneurs c'est la gestion du stockage. Certes c'est sympa d'en avoir plusieurs en même temps qui font exactement la même chose pour résister aux accidents, mais ils faut les synchroniser.
Cela me mène au principe suivant : si le service n'est pas persistant (aucun fichier ne change dedans quand il est en production) alors on fait un conteneur que l'on peut ainsi dupliquer. Si le service est persistant, alors on fait une VM avec une gestion propre du stockage et la possibilité de la migrer à chaud.
Vous avez totalement le droit de venir me taper dessus si vous n'êtes pas OK avec cela à condition de m'expliquer votre philosophie [N.D.L.R. : l'auteur initial de ce document est erdnaxe].
Exemples :