Pourquoi les conteneurs ne devraient pas s'exécuter en tant que root par défaut ?

Exécuter des conteneurs en tant que root est l'une des configurations erronées les plus courantes — et les plus dangereuses — dans les environnements de production. Cela élargit silencieusement la surface d'attaque de chaque charge de travail, et la plupart des équipes ne s'en rendent compte que lorsqu'un incident force le problème.

Ce que « s'exécuter en tant que root » signifie réellement

Par défaut, de nombreuses images de conteneur (en particulier les images minimales ou héritées) exécutent leur processus principal en tant que UID 0 à l'intérieur du conteneur. Comme les conteneurs partagent le noyau hôte avec d'autres conteneurs et l'hôte lui-même, root à l'intérieur d'un conteneur n'est pas le même que root sur une machine virtuelle complètement isolée — mais c'est toujours beaucoup plus puissant qu'il ne devrait l'être. Si un attaquant parvient à exécuter du code à l'intérieur d'un conteneur détenu par root, il hérite :

• D'un accès complet en lecture/écriture à tous les fichiers montés dans le conteneur, indépendamment des permissions prévues
• De la capacité à installer des paquets, modifier des binaires ou falsifier l'état de l'application
• D'un chemin beaucoup plus facile vers une fuite de conteneur si une vulnérabilité du noyau ou du runtime est exploitable
• D'un levier élevé combiné avec des volumes mal configurés, comme un socket Docker monté ou un chemin du système de fichiers de l'hôte

Même sans une exploitation au niveau du noyau, l'accès root à l'intérieur du conteneur augmente considérablement le rayon d'explosion de toute vulnérabilité au niveau de l'application (SSRF, bogues de désérialisation, écriture de fichier arbitraire, etc.).

Pourquoi cela est plus important dans les environnements orchestrés

Dans les clusters Kubernetes, un conteneur root associé à des capacités Linux excessives ou à un contexte de sécurité permissif peut permettre à un attaquant :

• De modifier /proc ou /sys de façons qui affectent l'hôte
• D'escalader les privilèges si hostPID, hostNetwork ou hostIPC sont activés
• D'abuser d'un jeton de compte de service monté pour effectuer un mouvement latéral à travers le cluster
• De s'échapper vers le nœud si privileged: true est défini ou si des capacités dangereuses comme SYS_ADMIN sont accordées

L'utilisateur root lui-même n'est pas toujours la vulnérabilité — c'est la combinaison de root plus des capacités du noyau excessivement généreuses, des montages d'hôte ou du partage d'espace de noms qui transforme une compromission contenue en une compromission au niveau du cluster.

Étapes pratiques de renforcement

1. Définir un utilisateur non-root dans l'image

Définissez explicitement un utilisateur non-root dans votre Dockerfile plutôt que de vous fier aux paramètres par défaut :

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. L'appliquer au niveau de l'orchestrateur

Ne vous fiez pas uniquement à l'image — appliquez la politique à l'exécution. Dans Kubernetes, utilisez un securityContext :

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true entraîne l'échec du pod à l'admission si l'image tente de s'exécuter en tant que UID 0, ce qui vous donne une garantie solide plutôt qu'une convention au meilleur effort.

3. Abandonner les capacités inutiles

La plupart des applications n'ont besoin d'aucune des capacités Linux par défaut accordées aux conteneurs. Abandonnez tout et ajoutez en arrière uniquement ce qui est strictement nécessaire (les cas rares comme se lier à des ports bas peuvent nécessiter NET_BIND_SERVICE).

4. Éviter le mode privilégié et le partage d'espace de noms d'hôte

privileged: true, hostNetwork: true et hostPID: true doivent être réservés à des charges de travail d'infrastructure très spécifiques (comme certains agents CNI ou de surveillance) — jamais pour les conteneurs d'application généraux.

5. Analyser et appliquer avec des outils de politique

Utilisez des contrôleurs d'admission ou des moteurs de politique (par exemple, Kyverno, OPA/Gatekeeper) pour rejeter automatiquement les déploiements qui violent ces règles, plutôt que de vous fier à l'examen manuel du code. Associez-le à une analyse d'image dans CI pour détecter les images utilisateur root avant qu'elles n'atteignent un cluster.

Une défense en couches, pas parfaite

S'exécuter en tant que non-root n'élimine pas complètement le risque — les fuites de conteneur au niveau du noyau existent indépendamment de l'utilisateur dans le conteneur — mais cela supprime une énorme classe de techniques d'escalade de privilèges et de mouvement latéral à faible effort. Combiné avec des systèmes de fichiers en lecture seule, des capacités abandonnées et des politiques réseau restrictives, cela constitue l'une des couches les moins chères et les plus efficaces dans une stratégie de sécurité des conteneurs de défense en profondeur.

Voulez-vous approfondir le renforcement des charges de travail cloud-native ? Explorez les segments Korra Studio connexes sur la sécurité cloud et le renforcement des pipelines DevOps pour construire le reste de votre stratégie de défense en profondeur.