Dites simplement non à la racine (dans des conteneurs)

On me demande tout le temps quelles sont les différentes mesures de sécurité utilisées pour contrôler ce que peuvent faire les processus de conteneur sur un système. J'ai couvert la plupart d'entre eux dans des articles précédents sur Opensource.com :

Les conteneurs Docker sont-ils vraiment sécurisés ?
Apporter de nouvelles fonctionnalités de sécurité à Docker
La sécurité Docker dans le futur

Presque tous les articles ci-dessus concernent le contrôle de ce qu'un processus privilégié sur un système peut faire dans un conteneur. Par exemple :comment puis-je exécuter root dans un conteneur et ne pas lui permettre d'éclater ?

Conteneurs Linux

Que sont les conteneurs Linux ?
Une introduction à la terminologie des conteneurs
Télécharger :Introduction aux conteneurs
Opérateurs Kubernetes :automatisation de la plate-forme d'orchestration de conteneurs
eBook :Modèles Kubernetes pour la conception d'applications cloud natives
Qu'est-ce que Kubernetes ?

L'espace de noms d'utilisateur consiste à exécuter des processus privilégiés dans des conteneurs, de sorte que s'ils éclatent, ils ne seraient plus privilégiés en dehors du conteneur. Par exemple, dans le conteneur, mon UID est 0 (zéro), mais en dehors du conteneur, mon UID est 5000. En raison de problèmes liés au manque de prise en charge du système de fichiers, l'espace de noms d'utilisateur n'a pas été la panacée qu'il est censé être. Jusqu'à maintenant.

OpenShift est la plate-forme de conteneurs de Red Hat, basée sur les conteneurs Kubernetes, Red Hat Enterprise Linux et OCI, et elle possède une excellente fonctionnalité de sécurité :par défaut, aucun conteneur n'est autorisé à s'exécuter en tant que root. Un administrateur peut remplacer cela, sinon tous les conteneurs d'utilisateurs s'exécutent sans jamais être root. Ceci est particulièrement important dans les clusters OpenShift Kubernetes mutualisés, où un seul cluster peut servir plusieurs applications et plusieurs équipes de développement. Il n'est pas toujours pratique ni même conseillé pour les administrateurs d'exécuter des clusters distincts pour chacun. Malheureusement, l'une des principales plaintes concernant OpenShift est que les utilisateurs ne peuvent pas exécuter facilement toutes les images de conteneurs communautaires disponibles sur docker.io. En effet, la grande majorité des images de conteneurs dans le monde nécessitent aujourd'hui une racine.

Pourquoi toutes ces images nécessitent-elles root ?

Si vous examinez réellement les raisons d'être root, sur un système, elles sont assez limitées.

Modifier le système hôte :

L'une des principales raisons d'être root sur le système est de modifier les paramètres par défaut du système, comme la modification de la configuration du noyau.
Dans Fedora, CentOS et Red Hat Enterprise Linux, nous avons le concept de conteneurs système , qui sont des conteneurs privilégiés qui peuvent être installés sur un système en utilisant le atomic commande. Ils peuvent s'exécuter avec tous les privilèges et sont autorisés à modifier le système ainsi que le noyau. Dans le cas de conteneurs système nous utilisons l'image du conteneur comme système de diffusion de contenu, sans vraiment rechercher la séparation des conteneurs. Les conteneurs système sont davantage destinés aux principaux services hôtes du système d'exploitation qu'aux services d'application des utilisateurs exécutés par la plupart des conteneurs.
Dans les conteneurs d'applications, nous ne voulons presque jamais que les processus à l'intérieur du conteneur modifient le noyau. Ce n'est certainement pas requis par défaut.

Tradition Unix/Linux :

Les éditeurs et les développeurs de logiciels de système d'exploitation savent depuis longtemps que l'exécution de processus en tant que root est dangereuse. Le noyau a donc ajouté de nombreuses fonctionnalités Linux pour permettre à un processus de démarrer en tant que root, puis de supprimer les privilèges le plus rapidement possible. La plupart des fonctionnalités UID/GID permettent à des processus tels qu'un service Web de démarrer en tant que root, puis de devenir non root. Ceci est fait pour se lier aux ports inférieurs à 1024 (plus sur cela plus tard).
Les environnements d'exécution de conteneur peuvent démarrer des applications en tant que non root pour commencer. La vérité est connue, systemd aussi, mais la plupart des logiciels qui ont été construits au cours des 20 dernières années supposent qu'ils démarrent en tant que root et suppriment les privilèges.

Lier aux ports <1024

Dans les années 1960 et 1970, alors qu'il y avait peu d'ordinateurs, l'incapacité des utilisateurs non privilégiés à se connecter aux ports réseau < 1024 était considérée comme une fonctionnalité de sécurité. Étant donné que seul un administrateur peut le faire, vous pouvez faire confiance aux applications qui écoutent sur ces ports. Les ports> 1024 peuvent être liés par n'importe quel utilisateur du système, de sorte qu'ils ne sont pas dignes de confiance. Les avantages en matière de sécurité ont largement disparu, mais nous vivons toujours avec cette restriction.
Le plus gros problème avec cette restriction est les services Web où les gens aiment avoir leurs serveurs Web à l'écoute sur le port 80. Cela signifie que la principale raison pour laquelle apache ou nginx commencent à s'exécuter en tant que root est qu'ils peuvent se lier au port 80, puis devenir non root.
Les environnements d'exécution de conteneur, utilisant le transfert de port, peuvent résoudre ce problème. Vous pouvez configurer un conteneur pour qu'il écoute sur n'importe quel port réseau, puis demander à l'environnement d'exécution du conteneur de mapper ce port sur le port 80 sur l'hôte.

Dans cette commande, le runtime podman exécuterait un apache_unpriv conteneur sur votre machine écoutant sur le port 80 sur l'hôte, alors que le processus Apache à l'intérieur du conteneur n'a jamais été root, démarré en tant que apache utilisateur, et dit d'écouter sur le port 8080.

podman run -d -p 80:8080 -u apache apache_unpriv

Sinon :

docker run -d -p 80:8080 -u apache apache_unpriv

Installer un logiciel dans une image de conteneur

Lorsque Docker a introduit la création de conteneurs avec docker build , le contenu des conteneurs n'était qu'un progiciel standard pour les distributions. Le logiciel est généralement fourni via des packages rpm ou des packages Debian. Eh bien, le logiciel de package de distributions doit être installé par root. Un paquet s'attend à pouvoir faire des choses comme manipuler le /etc/passwd fichier en ajoutant des utilisateurs et déposer du contenu sur le système de fichiers avec différents UID/GID. De nombreux logiciels s'attendent également à être démarrés via le système d'initialisation (systemd) et à démarrer en tant que root, puis à supprimer les privilèges après le démarrage.
Malheureusement, cinq ans après le début de la révolution des conteneurs, c'est toujours le statu quo. Il y a quelques années, j'ai tenté de faire savoir au paquet httpd quand il était installé par un utilisateur non root et d'avoir une configuration différente. Mais j'ai lâché la balle là-dessus. Nous devons faire en sorte que les conditionneurs et les systèmes de gestion des packages commencent à comprendre la différence, puis nous pourrions créer de beaux conteneurs qui s'exécutent sans nécessiter root.
Une chose que nous pourrions faire maintenant pour résoudre ce problème est de séparer les systèmes de construction des systèmes d'installation. L'un de mes problèmes avec #nobigfatdaemons est que le démon Docker a conduit les conteneurs à s'exécuter avec les mêmes privilèges pour exécuter un conteneur que pour créer une image de conteneur.
Si nous modifions le système ou utilisons des outils différents, par exemple Buildah, pour créer un conteneur avec des contraintes plus souples et CRI-O/Kubernetes/OpenShift pour exécuter les conteneurs en production, nous pouvons alors créer avec des privilèges élevés, mais ensuite exécuter le conteneurs avec des contraintes beaucoup plus strictes, ou, espérons-le, en tant que non root utilisateur.

Conclusion

Presque tous les logiciels que vous exécutez dans vos conteneurs ne le font pas nécessite root. Vos applications Web, bases de données, équilibreurs de charge, calculatrices de chiffres, etc. ne le font pas doivent toujours être exécutés en tant que root. Lorsque nous amenons les gens à commencer à créer des images de conteneurs qui ne nécessitent pas du tout de racine, et que d'autres basent leurs images sur des images de conteneurs non privilégiées, nous verrions un pas de géant dans la sécurité des conteneurs.

Il y a encore beaucoup d'éducation à faire autour de l'exécution de root à l'intérieur des conteneurs. Sans éducation, les administrateurs intelligents peuvent prendre de mauvaises décisions.