Choisir des images de confiance

Une image Docker peut contenir n'importe quel logiciel, y compris malveillant, si elle provient d'une source douteuse. Privilégiez les images officielles sur Docker Hub, comme node ou redis utilisées dans ce parcours, ou celles d'éditeurs vérifiés. Une image publiée par un compte inconnu, sans description ni source visible, mérite une vraie prudence avant d'être utilisée.

Ne jamais embarquer de secrets dans une image

Une image Docker, une fois construite, peut être partagée, poussée sur un registre, inspectée. Toute information sensible copiée dedans, comme un mot de passe écrit en dur dans le code ou un fichier .env oublié, y reste accessible à quiconque récupère cette image, même après suppression apparente du fichier dans une étape suivante du Dockerfile.

Vous avez déjà les bons réflexes depuis le guide 14 : un .dockerignore qui exclut .env, et des informations sensibles transmises en variables d'environnement au moment de docker run ou dans compose.yaml, jamais copiées dans l'image elle-même.

Ne pas exécuter en tant que root par défaut

Sans indication contraire, un processus dans un conteneur s'exécute avec les droits de l'utilisateur root, l'utilisateur avec le plus de privilèges possible. Si une faille venait à être exploitée dans l'application ou une de ses dépendances, un attaquant hériterait de ces mêmes privilèges à l'intérieur du conteneur. Beaucoup d'images officielles, dont node, fournissent déjà un utilisateur non privilégié prêt à l'emploi, nommé node :

USER node, placée avant CMD, fait que toutes les instructions suivantes, y compris le démarrage de l'application, s'exécutent avec les droits de cet utilisateur limité plutôt que root.

Bonne pratique

Ajoutez USER dès que l'image de base en propose un adapté, en particulier pour toute application qui reçoit des requêtes depuis l'extérieur, comme un serveur web. Ce n'est pas nécessaire pour un script ponctuel exécuté et jeté immédiatement, mais devient une vraie bonne pratique pour tout service qui reste actif durablement.

Garder ses images à jour

Une image de base ne s'améliore pas toute seule après sa construction. Des failles découvertes après coup dans Node.js, Alpine, ou une dépendance, ne sont corrigées que par une nouvelle construction, à partir d'une version à jour de l'image de base. Reconstruire régulièrement ses images, pas seulement au moment d'ajouter une fonctionnalité, fait partie d'une hygiène de sécurité de base.

Ne pas exposer un port sans réfléchir à ce qu'il révèle

Vous avez déjà croisé ce principe au guide 20 : Redis, sans mot de passe par défaut, reste sans risque tant qu'il n'est joignable que par d'autres conteneurs du même réseau Docker. Publier son port avec -p ou ports vers votre ordinateur, et a fortiori vers Internet, sans protection supplémentaire, l'exposerait directement à quiconque connaîtrait l'adresse. Avant de publier un port, demandez-vous toujours : ce service a-t-il vraiment besoin d'être joignable depuis l'extérieur du réseau Docker, ou seulement par les autres conteneurs qui en dépendent ?

Vérifiez que vous avez compris

Vous ajoutez USER node juste après WORKDIR /app, avant les instructions COPY et RUN npm install. Est-ce équivalent à l'ordre montré dans ce guide ?

Pas forcément sans ajustement. Si l'utilisateur node n'a pas les droits d'écriture nécessaires sur le dossier /app à ce stade, COPY ou RUN npm install pourraient échouer par manque de permissions. C'est justement pour cette raison que USER est généralement placé juste avant CMD, une fois que toutes les opérations nécessitant plus de droits, comme l'installation des dépendances, sont déjà terminées.

Chapitre terminé