Pourquoi monter docker.sock est-il dangereux ?

Questions d’entrevue Docker

Seniorsecuriteruntime

La réponse courte

Parce que docker.sock n’est pas « un peu d’API ». C’est le démon Docker, et le démon Docker est root sur l’hôte. Monter /var/run/docker.sock dans un conteneur, c’est donner à ce conteneur le droit de dire : crée un autre conteneur --privileged, monte / de l’hôte, lis /etc/shadow.

Le scénario tient en quatre lignes, et tout recruteur sérieux s’attend à ce que vous le racontiez :

text
conteneur « CI »  →  socket  →  dockerd (root)
                              →  docker run -v /:/host -u 0 alpine
                              →  chroot /host

À partir de là, namespaces et USER du premier conteneur ne comptent plus. Vous avez quitté l’isolement.

Les endroits où ça arrive « pour de bonnes raisons » : un agent Jenkins, un outil de preview, Traefik qui lit les labels, Portainer, un sidecar qui « gère » les autres conteneurs. La raison n’annule pas le privilège.

Ce que l’intervieweur vérifie

Que vous refusez l’argument « c’est un réseau interne, on se fait confiance ». Le socket est un privilège d’hôte, pas une commodité d’équipe. Il veut les alternatives, pas seulement la peur :

  • Construire sans démon. Kaniko, Buildah, BuildKit rootless, un builder distant. L’image se fabrique sans parler au Docker de l’hôte de prod.
  • Docker-in-Docker avec un démon à soi, pas le socket de l’hôte — plus lourd, mieux isolé, encore imparfait (seccomp, privileged souvent requis).
  • Socket proxy (le projet Tecnativa et équivalents) : n’exposer que create + logs, jamais run --privileged. Réduit, ne supprime pas.
  • Rootless Docker / user namespaces : baisse le gain d’une évasion, ne rend pas le socket anodin.

La phrase qui clôt : si ce conteneur est compromis — dépendance npm, RCE dans le dashboard — l’attaquant n’a plus un pod. Il a l’hyperviseur de fortune.

La relance probable

« On le monte en lecture seule, ça va ? »

Non. L’API Docker s’exprime en requêtes HTTP sur le socket. Lecture seule au montage Unix n’empêche pas un POST /containers/create. C’est une fausse mitigation qu’il faut savoir écarter.

« Et sur Kubernetes, le socket du nœud ? »

Pire : le rayon devient tous les nœuds qui acceptent ce DaemonSet. Le même raisonnement, à l’échelle du cluster.

Toutes les questions Docker