增强型容器隔离 (ECI) 常见问题解答
启用 ECI 后，我是否需要更改使用 Docker 的方式？
不需要，您可以继续像往常一样使用 Docker。ECI 在后台运行，创建一个更安全的容器。
所有容器工作负载都能与 ECI 良好地配合使用吗？
绝大多数容器工作负载可以在启用 ECI 的情况下正常运行，但少数工作负载不能（尚未）。对于那些尚未与增强型容器隔离配合使用的少数工作负载，Docker 正在继续改进此功能，以最大程度地减少这种情况。
我可以在 ECI 中运行特权容器吗？
是的，您可以在容器中使用 --privileged 标志，但与没有 ECI 的特权容器不同，该容器只能使用其提升的特权访问分配给该容器的资源。它无法访问 Docker Desktop Linux 虚拟机中的全局内核资源。这使您可以安全地运行特权容器（包括 Docker-in-Docker）。有关更多信息，请参见 主要功能和优势。
所有特权容器工作负载都可以在 ECI 中运行吗？
不能。希望访问 Docker Desktop Linux 虚拟机中的全局内核资源的特权容器工作负载将无法运行。例如，您无法使用特权容器加载内核模块。
为什么不直接限制 --privileged 标志的使用？
特权容器通常用于在容器中运行高级工作负载，例如 Docker-in-Docker 或 Kubernetes-in-Docker，执行内核操作（如加载模块）或访问硬件设备。
ECI 允许运行高级工作负载，但拒绝执行内核操作或访问硬件设备的能力。
ECI 是否会限制容器内的绑定挂载？
是的，它会限制将位于 Docker Desktop Linux 虚拟机中的目录绑定挂载到容器中。
它不会限制将您的主机文件绑定挂载到容器中，如通过 Docker Desktop 的 **设置** > **资源** > **文件共享** 配置的那样。
启用 ECI 后，我是否可以将主机的 Docker 套接字挂载到容器中？
默认情况下，ECI 会出于安全原因阻止将主机的 Docker 套接字绑定挂载到容器中。但是，此操作有一些合法用例，例如使用 Testcontainers 进行本地测试。
为了支持此类用例，可以配置 ECI 允许将 Docker 套接字挂载到容器中，但这仅限于您选择的（即，受信任的）容器镜像，甚至可以限制容器可以通过套接字发送到 Docker 引擎的命令。请参见 ECI Docker 套接字挂载权限。
ECI 是否会保护所有使用 Docker Desktop 启动的容器？
尚未。它会保护用户通过 docker create 和 docker run 启动的所有容器。
在 Docker Desktop 4.30 之前，它不会隐式地保护由 docker build 与 docker 构建驱动程序（默认驱动程序）一起使用的容器。从 Docker Desktop 4.30 开始，它会保护此类容器，但 Docker Desktop 在 WSL 2（Windows 主机）上除外。
请注意，自 Docker Desktop 4.19 起，在所有受支持的平台（带有 WSL 2 或 Hyper-V 的 Windows、Mac 和 Linux）上，ECI 始终会保护使用 docker-container 构建驱动程序 的 docker build 使用的容器。
ECI 尚未保护 Docker Desktop Kubernetes Pod、扩展容器和 开发环境容器。
ECI 是否会保护在启用 ECI 之前启动的容器？
不会。在启用 ECI 之前创建的容器不受保护。因此，我们建议在启用 ECI 之前删除所有容器。
ECI 是否会影响容器的性能？
ECI 对容器的性能影响很小。唯一的例外是执行大量 mount 和 umount 系统调用的容器，因为这些调用会被 Sysbox 容器运行时捕获和验证，以确保它们不被用于破坏容器的文件系统。
使用 ECI 后，用户是否仍可以从 CLI 覆盖 --runtime 标志？
不会。启用 ECI 后，Sysbox 会被设置为 Docker Desktop 用户部署容器的默认（也是唯一的）运行时。如果用户尝试覆盖运行时（例如，docker run --runtime=runc），则会忽略此请求，并且容器将通过 Sysbox 运行时创建。
之所以在 ECI 中禁用 runc，是因为它允许用户以“真实 root”身份在 Docker Desktop Linux 虚拟机中运行，从而为他们提供对虚拟机的隐式控制权，以及修改 Docker Desktop 管理配置的能力，例如。
ECI 与 Docker Engine 的 userns-remap 模式有何不同？
请参见 工作原理。
ECI 与无根 Docker 有何不同？
请参见 工作原理