L'accès au socket Docker équivaut à root sur l'hôte : ce que le monter dans un conteneur accorde vraiment

Ce que c'est

La documentation de sécurité de Docker indique que le démon requiert des privilèges root sauf en mode Rootless, et que seuls des comptes de confiance devraient pouvoir le contrôler. La raison invoquée : Docker permet de partager un répertoire entre l'hôte et un conteneur sans limiter les droits d'accès du conteneur, si bien qu'un conteneur peut être démarré avec la racine / de l'hôte montée et modifier librement le système de fichiers de l'hôte.

Le socket Unix /var/run/docker.sock est le canal de contrôle habituel. Quiconque peut y écrire contrôle le démon.

Pourquoi c'est important

Plusieurs configurations courantes accordent ce contrôle sans le dire :

• Monter le socket dans un conteneur afin qu'il puisse gérer d'autres conteneurs (exécuteurs de CI, tableaux de bord, mandataires inverses qui lisent des étiquettes, bacs à sable d'agents qui créent des conteneurs frères). La compromission de ce conteneur devient une compromission de l'hôte.
• Le groupe docker : en faire partie équivaut de fait à être root sur la machine.
• L'API TCP sans authentification client TLS, qui accorde la même chose à quiconque se trouve sur le réseau.

Pour les agents, le socket est séduisant parce qu'il rend facile le « exécuter ceci dans un conteneur » ; cela signifie aussi que le bac à sable peut s'en échapper avec un seul appel d'API.

Comment l'appliquer

• Inventorier quels conteneurs montent le socket : docker inspect sur tous les conteneurs, en cherchant le chemin du socket parmi les montages.
• Là où un outil ne fait que lire les métadonnées des conteneurs, placer un mandataire filtrant devant le socket qui n'autorise que les points de terminaison en lecture seule nécessaires, et monter celui-ci à la place.
• Faire tourner les bacs à sable d'agents qui doivent démarrer des conteneurs avec le mode Rootless, un démon séparé, ou une frontière de VM plutôt qu'avec le démon de l'hôte.
• Garder le groupe docker aussi restreint que la liste sudoers, et revoir les deux ensemble.
• Ne jamais exposer l'API sur TCP sans authentification TLS mutuelle ; préférer un accès au socket par SSH.

Pièges

• Un montage du socket en lecture seule (:ro) : cela empêche de remplacer le fichier du socket, pas d'y envoyer des requêtes d'API.
• Supposer que les espaces de noms utilisateur ou un compte non root à l'intérieur du conteneur changent quoi que ce soit ; le démon qui agit sur la requête reste root.