Comprendre les exigences d'autorisation pour Windows

Cette page contient des informations sur les exigences d'autorisation pour exécuter et installer Docker Desktop sur Windows, la fonctionnalité du processus d'assistant privilégié com.docker.service, et le raisonnement derrière cette approche.

Elle fournit également des clarifications sur l'exécution de conteneurs en tant que root par opposition à avoir un accès Administrator sur l'hôte et les privilèges du moteur Docker Windows et des conteneurs Windows.

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

Exigences d'autorisation

Bien que Docker Desktop sur Windows puisse être exécuté sans avoir de privilèges Administrator, il en nécessite pendant l'installation. À l'installation, vous recevez une invite UAC qui permet d'installer un service d'assistant privilégié. Après cela, Docker Desktop peut être exécuté sans privilèges administrateur, à condition que vous soyez membre du groupe docker-users. Si vous avez effectué l'installation, vous êtes automatiquement ajouté à ce groupe, mais d'autres utilisateurs doivent être ajoutés manuellement. Cela permet à l'administrateur de contrôler qui a accès à Docker Desktop.

La raison de cette approche est que Docker Desktop doit effectuer un ensemble limité d'opérations privilégiées qui sont menées par le processus d'assistant privilégié com.docker.service. Cette approche permet, en suivant le principe du moindre privilège, que l'accès Administrator soit utilisé uniquement pour les opérations pour lesquelles il est absolument nécessaire, tout en étant capable d'utiliser Docker Desktop en tant qu'utilisateur non privilégié.

Assistant privilégié

L'assistant privilégié com.docker.service est un service Windows qui s'exécute en arrière-plan avec des privilèges SYSTEM. Il écoute sur le pipe nommé //./pipe/dockerBackendV2. Le développeur exécute l'application Docker Desktop, qui se connecte au pipe nommé et envoie des commandes au service. Ce pipe nommé est protégé, et seuls les utilisateurs qui font partie du groupe docker-users peuvent y avoir accès.

Le service effectue les fonctionnalités suivantes :

• S'assurer que kubernetes.docker.internal est défini dans le fichier hosts Win32. Définir le nom DNS kubernetes.docker.internal permet à Docker de partager les contextes Kubernetes avec les conteneurs.
• S'assurer que host.docker.internal et gateway.docker.internal sont définis dans le fichier hosts Win32. Ils pointent vers l'adresse IP locale de l'hôte et permettent à une application de résoudre l'IP de l'hôte en utilisant le même nom depuis l'hôte lui-même ou un conteneur.
• 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.
• Création de la VM Hyper-V "DockerDesktopVM" et gestion de son cycle de vie - démarrage, arrêt et destruction. Le nom de la VM est codé en dur dans le code du service donc le service ne peut pas être utilisé pour créer ou manipuler d'autres VM.
• Déplacement du fichier ou dossier VHDX.
• Démarrage et arrêt du moteur Docker Windows et vérification s'il fonctionne.
• Suppression de tous les fichiers de données des conteneurs Windows.
• Vérification si Hyper-V est activé.
• Vérification si le chargeur de démarrage active Hyper-V.
• Vérification si les fonctionnalités Windows requises sont à la fois installées et activées.
• Réalisation de vérifications de santé et récupération de la version du service lui-même.

Le mode de démarrage du service dépend du moteur de conteneur sélectionné, et, pour WSL, de s'il est nécessaire de maintenir host.docker.internal et gateway.docker.internal dans le fichier hosts Win32. Ceci est contrôlé par un paramètre sous Use the WSL 2 based engine dans la page de paramètres. Lorsque ceci est défini, le moteur WSL se comporte de la même manière qu'Hyper-V. Donc :

• Avec les conteneurs Windows, ou les conteneurs Linux Hyper-v, le service est démarré lorsque le système démarre et fonctionne tout le temps, même lorsque Docker Desktop ne fonctionne pas. Ceci est requis pour que vous puissiez lancer Docker Desktop sans privilèges admin.
• Avec les conteneurs Linux WSL2, le service n'est pas nécessaire et par conséquent ne s'exécute pas automatiquement lorsque le système démarre. Lorsque vous basculez vers les conteneurs Windows ou les conteneurs Linux Hyper-V, ou choisissez de maintenir host.docker.internal et gateway.docker.internal dans le fichier hosts Win32, une invite UAC apparaît vous demandant d'accepter l'opération privilégiée pour démarrer le service. Si accepté, le service est démarré et configuré pour démarrer automatiquement au prochain démarrage de Windows.

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

Le démon Docker Linux et les conteneurs s'exécutent dans une VM Linux minimale à usage spécial gérée par Docker. Elle est immuable donc vous ne pouvez pas l'étendre ou changer les logiciels installés. Cela signifie que bien que les conteneurs s'exécutent par défaut en tant que root, cela ne permet pas de modifier la VM et n'accorde pas un accès Administrator à la machine hôte Windows. La VM Linux sert de limite de sécurité et limite les ressources de l'hôte qui peuvent être accessibles. Le partage de fichiers utilise un serveur de fichiers créé en espace utilisateur et tous les répertoires de l'hôte montés par liaison dans les conteneurs Docker conservent toujours leurs permissions originales. Les conteneurs n'ont pas accès aux fichiers de l'hôte au-delà de ceux explicitement partagés.

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.

Conteneurs Windows

Warning

Activer les conteneurs Windows a des implications de sécurité importantes.

Contrairement au moteur Docker Linux et aux conteneurs qui s'exécutent dans une VM, les conteneurs Windows sont implémentés en utilisant les fonctionnalités du système d'exploitation, et s'exécutent directement sur l'hôte Windows. Si vous activez les conteneurs Windows pendant l'installation, l'utilisateur ContainerAdministrator utilisé pour l'administration à l'intérieur du conteneur est un administrateur local sur la machine hôte. Activer les conteneurs Windows pendant l'installation fait en sorte que les membres du groupe docker-users sont capables de s'élever aux administrateurs sur l'hôte. Pour les organisations qui ne veulent pas que leurs développeurs exécutent des conteneurs Windows, un drapeau d'installateur --no-windows-containers est disponible pour désactiver leur utilisation.

Réseau

Pour la connectivité réseau, Docker Desktop utilise un processus d'espace utilisateur (vpnkit), qui hérite des contraintes comme les règles de pare-feu, VPN, propriétés de proxy HTTP, etc. de l'utilisateur qui l'a lancé.