FAQ sur l'Isolation de Conteneurs Renforcée
Dois-je changer ma façon d'utiliser Docker quand ECI est activé ?
Non, vous pouvez continuer à utiliser Docker comme d'habitude. ECI fonctionne en arrière-plan en créant un conteneur plus sécurisé.
Toutes les charges de travail de conteneur fonctionnent-elles bien avec ECI ?
La grande majorité des charges de travail de conteneur fonctionnent bien avec ECI activé, mais quelques-unes ne fonctionnent pas (encore). Pour les quelques charges de travail qui ne fonctionnent pas encore avec l'Isolation de Conteneurs Renforcée, Docker continue d'améliorer la fonctionnalité pour réduire cela au minimum.
Puis-je exécuter des conteneurs privilégiés avec ECI ?
Oui, vous pouvez utiliser le flag --privileged dans les conteneurs mais contrairement aux conteneurs privilégiés sans ECI, le conteneur ne peut utiliser ses privilèges élevés que pour accéder aux ressources assignées au conteneur. Il ne peut pas accéder aux ressources globales du noyau dans la VM Linux Docker Desktop. Cela vous permet d'exécuter des conteneurs privilégiés de manière sécurisée (y compris Docker-in-Docker). Pour plus d'informations, voir Fonctionnalités et avantages clés.
Toutes les charges de travail de conteneur privilégié fonctionneront-elles avec ECI ?
Non. Les charges de travail de conteneur privilégié qui veulent accéder aux ressources globales du noyau à l'intérieur de la VM Linux Docker Desktop ne fonctionneront pas. Par exemple, vous ne pouvez pas utiliser un conteneur privilégié pour charger un module noyau.
Pourquoi ne pas simplement restreindre l'usage du flag --privileged ?
Les conteneurs privilégiés sont typiquement utilisés pour exécuter des charges de travail avancées dans les conteneurs, par exemple Docker-in-Docker ou Kubernetes-in-Docker, pour effectuer des opérations de noyau telles que le chargement de modules, ou pour accéder aux périphériques matériels.
ECI permet l'exécution de charges de travail avancées, mais refuse la capacité d'effectuer des opérations de noyau ou d'accéder aux périphériques matériels.
ECI restreint-il les montages par liaison à l'intérieur du conteneur ?
Oui, il restreint les montages par liaison des répertoires situés dans la VM Linux Docker Desktop dans le conteneur.
Il ne restreint pas les montages par liaison des fichiers de votre machine hôte dans le conteneur, comme configuré via Paramètres > Ressources > Partage de Fichiers de Docker Desktop.
Puis-je monter le Socket Docker de l'hôte dans un conteneur quand ECI est activé ?
Par défaut, ECI bloque le montage par liaison du socket Docker de l'hôte dans les conteneurs, pour des raisons de sécurité. Cependant, il existe des cas d'usage légitimes pour cela, par exemple lors de l'utilisation de Testcontainers pour les tests locaux.
Pour permettre de tels cas d'usage, il est possible de configurer ECI pour autoriser les montages de socket Docker dans les conteneurs, mais seulement pour vos images de conteneur choisies (c'est-à-dire, de confiance), et même restreindre quelles commandes le conteneur peut envoyer au Docker Engine via le socket. Voir Permissions de montage de socket Docker ECI.
ECI protège-t-il tous les conteneurs lancés avec Docker Desktop ?
Pas encore. Il protège tous les conteneurs lancés par les utilisateurs via docker create et docker run.
Pour les conteneurs implicitement créés par docker build ainsi que le Kubernetes intégré de Docker Desktop, la protection varie selon la version de Docker Desktop (voir les deux FAQ suivantes).
ECI protège-t-il les conteneurs implicitement utilisés par docker build ?
Avant Docker Desktop 4.19, ECI ne protégeait pas les conteneurs utilisés implicitement par docker build pendant le processus de construction.
Depuis Docker Desktop 4.19, ECI protège les conteneurs utilisés par docker build lors de l'utilisation du
driver de conteneur Docker.
De plus, depuis Docker Desktop 4.30, ECI protège aussi les conteneurs utilisés par docker build lors de l'utilisation du driver de construction "docker" par défaut, sur toutes les plateformes supportées par Docker Desktop sauf Windows avec WSL 2.
ECI protège-t-il Kubernetes dans Docker Desktop ?
Avant Docker Desktop 4.38, ECI ne protégeait pas le cluster Kubernetes intégré dans Docker Desktop.
Depuis Docker Desktop 4.38, ECI protège le cluster Kubernetes intégré lors de l'utilisation du nouveau provisionneur kind (voir Déployer sur Kubernetes). Dans ce cas, chaque nœud dans le cluster Kubernetes multi-nœuds est en fait un conteneur protégé par ECI. Avec ECI désactivé, chaque nœud dans le cluster Kubernetes est un conteneur entièrement privilégié moins sécurisé.
ECI ne protège pas le cluster Kubernetes intégré lors de l'utilisation de l'ancien provisionneur de cluster à nœud unique Kubeadm.
ECI protège-t-il les conteneurs lancés avant d'activer ECI ?
Non. Les conteneurs créés avant d'activer ECI ne sont pas protégés. Par conséquent, il est recommandé de supprimer tous les conteneurs avant d'activer ECI.
ECI affecte-t-il les performances des conteneurs ?
ECI a peu d'impact sur les performances des conteneurs. L'exception concerne les conteneurs qui effectuent beaucoup d'appels système mount et umount, car ceux-ci sont interceptés et vérifiés par le runtime de conteneur Sysbox pour s'assurer qu'ils ne sont pas utilisés pour violer le système de fichiers du conteneur.
Avec ECI, l'utilisateur peut-il encore outrepasser le flag --runtime depuis la CLI ?
Non. Avec ECI activé, Sysbox est défini comme le runtime par défaut (et unique) pour les conteneurs déployés par les utilisateurs de Docker Desktop. Si un utilisateur tente d'outrepasser le runtime (par ex., docker run --runtime=runc), cette demande est ignorée et le conteneur est créé via le runtime Sysbox.
La raison pour laquelle runc est interdit est qu'il permet aux utilisateurs de s'exécuter en tant que "vrai root" sur la VM Linux Docker Desktop, leur fournissant ainsi un contrôle implicite de la VM et la capacité de modifier les configurations administratives pour Docker Desktop.
En quoi ECI est-il différent du mode userns-remap de Docker Engine ?
Voir Comment cela fonctionne.