⚠️ Traduction non officielle - Cette documentation est une traduction communautaire non officielle de Docker.

Comprendre les exigences d'autorisation pour Docker Desktop sur Mac

Table des matières

Cette page contient des informations sur les exigences d'autorisation pour exécuter et installer Docker Desktop sur Mac.

Elle fournit également des clarifications sur l'exécution de conteneurs en tant que root par opposition à avoir un accès root sur l'hôte.

Docker Desktop sur Mac est conçu avec la sécurité à l'esprit. Les droits administratifs ne sont requis que lorsqu'absolument nécessaire.

Exigences d'autorisation

Docker Desktop pour Mac est exécuté en tant qu'utilisateur non privilégié. Cependant, Docker Desktop nécessite certaines fonctionnalités pour effectuer un ensemble limité de configurations privilégiées telles que :

  • Installation de liens symboliques dans /usr/local/bin.
  • Liaison de ports privilégiés qui sont inférieurs à 1024. Bien que les ports privilégiés (ports inférieurs à 1024) ne soient généralement pas utilisés comme limite de sécurité, les systèmes d'exploitation empêchent toujours les processus non privilégiés de s'y lier, ce qui brise des commandes comme docker run -p 127.0.0.1:80:80 docker/getting-started.
  • Assurer que localhost et kubernetes.docker.internal sont définis dans /etc/hosts. Certaines anciennes installations macOS n'ont pas localhost dans /etc/hosts, ce qui cause l'échec de Docker. Définir le nom DNS kubernetes.docker.internal permet à Docker de partager les contextes Kubernetes avec les conteneurs.
  • Mise en cache sécurisée de la politique de Gestion d'Accès au Registre qui est en lecture seule pour le développeur.

L'accès privilégié est accordé pendant l'installation.

La première fois que Docker Desktop pour Mac se lance, il présente une fenêtre d'installation où vous pouvez choisir soit d'utiliser les paramètres par défaut, qui fonctionnent pour la plupart des développeurs et nécessitent que vous accordiez un accès privilégié, soit d'utiliser les paramètres avancés.

Si vous travaillez dans un environnement avec des exigences de sécurité élevées, par exemple où l'accès administratif local est interdit, alors vous pouvez utiliser les paramètres avancés pour supprimer le besoin d'accorder un accès privilégié. Vous pouvez configurer :

  • L'emplacement des outils CLI Docker soit dans le répertoire système ou utilisateur
  • Le socket Docker par défaut
  • Le mappage de ports privilégiés

Selon les paramètres avancés que vous configurez, vous devez entrer votre mot de passe pour confirmer.

Vous pouvez modifier ces configurations à une date ultérieure depuis la page Avancé dans Paramètres.

Installation de liens symboliques

Les binaires Docker sont installés par défaut dans /Applications/Docker.app/Contents/Resources/bin. Docker Desktop crée des liens symboliques pour les binaires dans /usr/local/bin, ce qui signifie qu'ils sont automatiquement inclus dans PATH sur la plupart des systèmes.

Vous pouvez choisir d'installer les liens symboliques soit dans /usr/local/bin ou $HOME/.docker/bin pendant l'installation de Docker Desktop.

Si /usr/local/bin est choisi, et que cet emplacement n'est pas accessible en écriture par les utilisateurs non privilégiés, Docker Desktop nécessite une autorisation pour confirmer ce choix avant que les liens symboliques vers les binaires Docker soient créés dans /usr/local/bin. Si $HOME/.docker/bin est choisi, aucune autorisation n'est requise, mais alors vous devez ajouter manuellement $HOME/.docker/bin à votre PATH.

Vous avez également la possibilité d'activer l'installation du lien symbolique /var/run/docker.sock. Créer ce lien symbolique assure que divers clients Docker s'appuyant sur le chemin de socket Docker par défaut fonctionnent sans modifications supplémentaires.

Comme /var/run est monté en tant que tmpfs, son contenu est supprimé au redémarrage, lien symbolique vers le socket Docker inclus. Pour s'assurer que le socket Docker existe après le redémarrage, Docker Desktop configure une tâche de démarrage launchd qui crée le lien symbolique en exécutant ln -s -f /Users/<user>/.docker/run/docker.sock /var/run/docker.sock. Cela assure que vous n'êtes pas invité à chaque démarrage à créer le lien symbolique. Si vous n'activez pas cette option à l'installation, le lien symbolique et la tâche de démarrage ne sont pas créés et vous pourriez devoir définir explicitement la variable d'environnement DOCKER_HOST à /Users/<user>/.docker/run/docker.sock dans les clients que vous utilisez. Le CLI Docker s'appuie sur le contexte actuel pour récupérer le chemin du socket, le contexte actuel est défini sur desktop-linux au démarrage de Docker Desktop.

Liaison de ports privilégiés

Vous pouvez choisir d'activer le mappage de ports privilégiés pendant l'installation, ou depuis la page Avancé dans Paramètres après l'installation. Docker Desktop nécessite une autorisation pour confirmer ce choix.

Assurer que localhost et kubernetes.docker.internal sont définis

Il est de votre responsabilité de vous assurer que localhost est résolu en 127.0.0.1 et si Kubernetes est utilisé, que kubernetes.docker.internal est résolu en 127.0.0.1.

Installation depuis la ligne de commande

Les configurations privilégiées sont appliquées pendant l'installation avec le drapeau --user sur la commande install. Dans ce cas, vous n'êtes pas invité à accorder des privilèges root au premier lancement de Docker Desktop. Spécifiquement, le drapeau --user :

  • Désinstalle le précédent com.docker.vmnetd s'il est présent
  • Configure les liens symboliques
  • S'assure que localhost est résolu en 127.0.0.1

La limitation de cette approche est que Docker Desktop ne peut être exécuté que par un seul compte utilisateur par machine, à savoir celui spécifié dans le drapeau --user.

Assistant privilégié

Dans les situations limitées où l'assistant privilégié est nécessaire, par exemple lier des ports privilégiés ou mettre en cache la politique de Gestion d'Accès au Registre, l'assistant privilégié est démarré par launchd et s'exécute en arrière-plan à moins qu'il ne soit désactivé au moment de l'exécution comme décrit précédemment. Le backend Docker Desktop communique avec l'assistant privilégié via le socket de domaine UNIX /var/run/com.docker.vmnetd.sock. Les fonctionnalités qu'il effectue sont :

  • Liaison de ports privilégiés qui sont inférieurs à 1024.
  • Mise en cache sécurisée de la politique de Gestion d'Accès au Registre qui est en lecture seule pour le développeur.
  • Désinstallation de l'assistant privilégié.

La suppression du processus d'assistant privilégié se fait de la même manière que la suppression des processus launchd.

$ ps aux | grep vmnetd
root             28739   0.0  0.0 34859128    228   ??  Ss    6:03PM   0:00.06 /Library/PrivilegedHelperTools/com.docker.vmnetd
user             32222   0.0  0.0 34122828    808 s000  R+   12:55PM   0:00.00 grep vmnetd

$ sudo launchctl unload -w /Library/LaunchDaemons/com.docker.vmnetd.plist
Password:

$ ps aux | grep vmnetd
user             32242   0.0  0.0 34122828    716 s000  R+   12:55PM   0:00.00 grep vmnetd

$ rm /Library/LaunchDaemons/com.docker.vmnetd.plist

$ rm /Library/PrivilegedHelperTools/com.docker.vmnetd

Conteneurs s'exécutant en tant que root dans la VM Linux

Avec Docker Desktop, le démon Docker et les conteneurs s'exécutent dans une VM Linux légère gérée par Docker. Cela signifie que bien que les conteneurs s'exécutent par défaut en tant que root, cela n'accorde pas un accès root à la machine hôte Mac. La VM Linux sert de limite de sécurité et limite les ressources qui peuvent être accessibles depuis l' hôte. Tous les répertoires de l'hôte montés par liaison dans les conteneurs Docker conservent toujours leurs permissions originales.

Isolation de Conteneurs Renforcée

De plus, Docker Desktop prend en charge le mode Isolation de Conteneurs Renforcée (ECI), disponible uniquement pour les clients Business, qui sécurise davantage les conteneurs sans impacter les flux de travail des développeurs.

ECI exécute automatiquement tous les conteneurs dans un espace de noms utilisateur Linux, de sorte que root dans le conteneur est mappé à un utilisateur non privilégié à l'intérieur de la VM Docker Desktop. ECI utilise cela et d'autres techniques avancées pour sécuriser davantage les conteneurs dans la VM Linux Docker Desktop, de sorte qu'ils sont davantage isolés du démon Docker et d'autres services s'exécutant à l'intérieur de la VM.