Sécurité des conteneurs à l’exécution

Bienvenue dans la sécurité des conteneurs à l’exécution ! Créer des images sécurisées est essentiel, mais que se passe-t-il une fois votre conteneur en fonctionnement ?

Cette leçon porte sur les bonnes pratiques permettant de protéger vos applications pendant leur fonctionnement, en limitant les dommages potentiels causés par des vulnérabilités ou des attaques.

Un concept fondamental de la sécurité est le principe du moindre privilège. Il consiste à n’accorder à une entité (comme un conteneur ou un utilisateur) que les permissions absolument nécessaires à l’exécution de sa fonction, et aucune de plus.

Cette approche réduit la surface d’attaque et limite l’impact potentiel si un conteneur est compromis.

Par défaut, les processus à l’intérieur d’un conteneur Docker s’exécutent en tant qu’utilisateur root, qui dispose de privilèges administratifs complets dans le conteneur.

• Risque : Si un attaquant prend le contrôle d’un conteneur doté des privilèges root, il pourrait exploiter des vulnérabilités du démon Docker ou du noyau afin d’obtenir un accès root sur le système hôte.
• Bonne pratique : Exécutez toujours les processus de vos conteneurs avec un utilisateur qui n’est pas root.

Vous pouvez spécifier un utilisateur (par son nom ou son UID) pour le processus de votre conteneur à l’aide de l’option --user avec docker run. Ici, nous exécutons la commande id dans un conteneur Alpine en tant qu’utilisateur 1000.

Si l’utilisateur 1000 n’existe pas, Docker utilisera tout de même cet UID.

Les systèmes Linux traditionnels disposent d’un utilisateur root fonctionnant selon le principe du « tout ou rien ». Les capacités Linux décomposent les puissants privilèges root en unités plus petites et distinctes.

Ainsi, un processus peut disposer uniquement des pouvoirs spécifiques similaires à ceux de root dont il a besoin (par exemple, l’association à des ports bas ou l’accès réseau brut), sans bénéficier de tous les privilèges root.

Par défaut, les conteneurs Docker s’exécutent avec un ensemble étendu de capacités. Vous pouvez supprimer les capacités inutiles à l’aide de --cap-drop afin de restreindre davantage les actions possibles d’un conteneur.

Ici, nous supprimons la capacité NET_RAW. La commande ping, qui nécessite NET_RAW, échouera alors, ce qui démontrera la restriction.

Les conteneurs partagent le noyau et les ressources de l’hôte. Une utilisation incontrôlée des ressources par un conteneur peut provoquer un déni de service (DoS) pour les autres conteneurs, voire pour l’hôte lui-même.

• Limites du CPU : Empêchent un conteneur de monopoliser les cycles processeur.
• Limites de mémoire : Empêchent un conteneur de consommer toute la RAM disponible et de déstabiliser le système.

Vous pouvez définir directement des limites de CPU et de mémoire avec docker run. Cet exemple limite la mémoire à 128 Mo et l’utilisation du CPU à 0,5 (la moitié d’un cœur CPU).

Votre conteneur se comporte ainsi correctement et n’épuise pas les ressources des autres processus.

De nombreuses applications n’ont pas besoin d’écrire dans leur système de fichiers racine après leur démarrage. En rendant le système de fichiers accessible en lecture seule, vous bénéficiez d’importants avantages en matière de sécurité :

• Empêche les altérations : Un attaquant ne peut pas modifier les fichiers existants ni écrire de nouveaux fichiers malveillants.
• Limite la persistance : Toute modification effectuée est éphémère et est perdue au redémarrage du conteneur.
• Applique l’immutabilité : Favorise une conception dans laquelle les conteneurs sont jetables et la configuration est externe.

Utilisez l’option --read-only lors du démarrage d’un conteneur. Toute tentative d’écriture dans le système de fichiers du conteneur (en dehors des volumes montés explicitement) échouera.

Essayez de créer un fichier dans ce conteneur en lecture seule :

Lesquelles des pratiques suivantes sont recommandées pour sécuriser les conteneurs à l’exécution ?

Excellent travail ! Vous avez appris à renforcer la sécurité des conteneurs pendant leur fonctionnement :

• Moindre privilège : N’accordez que les permissions nécessaires.
• Utilisateurs non root : Évitez d’exécuter les processus en tant que root.
• Capacités : Supprimez les capacités Linux inutiles.
• Limites de ressources : Contrôlez l’utilisation du CPU et de la mémoire.
• Lecture seule : Rendez les systèmes de fichiers immuables afin d’empêcher les écritures.

Ces pratiques réduisent considérablement la surface d’attaque et l’impact des compromissions potentielles. Continuez à vous entraîner !