Limitations

Support d'ECI pour WSL

Note

Docker Desktop nécessite WSL 2 version 2.1.5 ou ultérieure. Pour obtenir la version actuelle de WSL sur votre hôte, tapez wsl --version. Si la commande échoue ou si elle retourne un numéro de version antérieur à 2.1.5, mettez à jour WSL vers la dernière version en tapant wsl --update dans un terminal de commande Windows ou PowerShell.

ECI sur WSL n'est pas aussi sécurisé que sur Hyper-V car :

• Bien qu'ECI sur WSL durcisse toujours les conteneurs de sorte que les charges de travail malveillantes ne puissent pas facilement violer la VM Linux de Docker Desktop, ECI sur WSL ne peut pas empêcher les utilisateurs de Docker Desktop de violer la VM Linux Docker Desktop. De tels utilisateurs peuvent trivialement accéder à cette VM (en tant que root) avec la commande wsl -d docker-desktop, et utiliser cet accès pour modifier les paramètres de Docker Engine à l'intérieur de la VM. Cela donne aux utilisateurs de Docker Desktop le contrôle de la VM Docker Desktop et leur permet de contourner les configurations Docker Desktop définies par les administrateurs via la fonctionnalité gestion des paramètres. En revanche, ECI sur Hyper-V ne permet pas aux utilisateurs de Docker Desktop de violer la VM Linux Docker Desktop.

• Avec WSL 2, toutes les distributions WSL 2 sur le même hôte Windows partagent la même instance du noyau Linux. En conséquence, Docker Desktop ne peut pas garantir l'intégrité du noyau dans la VM Linux Docker Desktop puisqu'une autre distribution WSL 2 pourrait modifier les paramètres partagés du noyau. En revanche, lors de l'utilisation d'Hyper-V, la VM Linux Docker Desktop a un noyau dédié qui est uniquement sous le contrôle de Docker Desktop.

Le tableau suivant résume cela.

En général, utiliser ECI avec Hyper-V est plus sécurisé qu'avec WSL 2. Mais WSL 2 offre des avantages pour les performances et l'utilisation des ressources sur la machine hôte, et c'est un excellent moyen pour les utilisateurs d'exécuter leur distribution Linux favorite sur des hôtes Windows et d'accéder à Docker depuis l'intérieur.

Protection ECI pour les constructions Docker avec le driver "docker"

Avant Docker Desktop 4.30, les commandes docker build qui utilisent le driver buildx docker (par défaut) ne sont pas protégées par ECI, en d'autres termes la construction s'exécute rootful à l'intérieur de la VM Docker Desktop.

À partir de Docker Desktop 4.30, les commandes docker build qui utilisent le driver buildx docker sont protégées par ECI, sauf quand Docker Desktop est configuré pour utiliser WSL 2 (sur les hôtes Windows).

Notez que les commandes docker build qui utilisent le driver docker-container sont toujours protégées par ECI.

Docker Build et Buildx ont quelques restrictions

Avec ECI activé, Docker build --network=host et les droits Docker Buildx (network.host, security.insecure) ne sont pas autorisés. Les constructions qui nécessitent ceux-ci ne fonctionneront pas correctement.

Les pods Kubernetes ne sont pas encore protégés

Lors de l'utilisation du Kubernetes intégré de Docker Desktop, les pods ne sont pas encore protégés par ECI. Par conséquent, un pod malveillant ou privilégié peut compromettre la VM Linux Docker Desktop et contourner les contrôles de sécurité.

Comme alternative, vous pouvez utiliser l'outil K8s.io KinD avec ECI. Dans ce cas, chaque nœud Kubernetes s'exécute à l'intérieur d'un conteneur protégé par ECI, isolant ainsi plus fortement le cluster Kubernetes de la VM Linux Docker Desktop sous-jacente (et Docker Engine à l'intérieur). Aucun arrangement spécial n'est nécessaire, activez simplement ECI et exécutez l'outil KinD comme d'habitude.

Les conteneurs d'extension ne sont pas encore protégés

Les conteneurs d'extension ne sont pas non plus encore protégés par ECI. Assurez-vous que vos conteneurs d'extension proviennent d'entités de confiance pour éviter les problèmes.

Les conteneurs Docker Debug ne sont pas encore protégés

Les conteneurs Docker Debug ne sont pas encore protégés par ECI.

Les conteneurs Windows natifs ne sont pas supportés

ECI ne fonctionne que quand Docker Desktop est en mode conteneurs Linux (le mode par défaut, le plus commun). Il n'est pas supporté quand Docker Desktop est configuré en mode conteneurs Windows natifs (c'est-à-dire, il n'est pas supporté sur les hôtes Windows, quand Docker Desktop est basculé de son mode Linux par défaut vers le mode Windows natif).

Utilisation en production

En général, les utilisateurs ne devraient pas constater de différences entre l'exécution d'un conteneur dans Docker Desktop avec ECI activé, qui utilise le runtime Sysbox, et l'exécution de ce même conteneur en production, via le runtime OCI runc standard.

Cependant dans certains cas, typiquement lors de l'exécution de charges de travail avancées ou privilégiées dans les conteneurs, les utilisateurs peuvent constater quelques différences. En particulier, le conteneur peut s'exécuter avec ECI mais pas avec runc, ou vice-versa.