增强的容器隔离常见问题
启用 ECI 后,我是否需要更改使用 Docker 的方式?
不,您可以继续像往常一样使用 Docker。ECI 在后台工作,通过创建一个更安全的容器。
所有容器工作负载都能与 ECI 良好配合吗?
绝大多数容器工作负载都能在启用 ECI 的情况下正常运行,但少数几个(目前)不能。对于少数几个尚无法与增强型容器隔离配合使用的 工作负载,Docker 正在不断改进此功能,以最大限度地减少这种情况。
我可以使用 ECI 运行特权容器吗?
是的,您可以在容器中使用--privileged
标志,但与没有 ECI 的特权容器不同,容器只能使用其提升的权限访问分配给容器的资源。它无法访问 Docker Desktop Linux VM 中的全局内核资源。这使您可以安全地运行特权容器(包括 Docker-in-Docker)。有关更多信息,请参阅主要功能和优势。
所有特权容器工作负载都能与 ECI 一起运行吗?
不可以。想要访问 Docker Desktop Linux VM 内的全局内核资源的特权容器工作负载将无法工作。例如,您无法使用特权容器加载内核模块。
为什么不只是限制使用--privileged
标志?
特权容器通常用于在容器中运行高级工作负载,例如 Docker-in-Docker 或 Kubernetes-in-Docker,以执行内核操作(例如加载模块)或访问硬件设备。
ECI 允许运行高级工作负载,但拒绝执行内核操作或访问硬件设备的能力。
ECI 是否限制容器内的绑定挂载?
是的,它会限制将位于 Docker Desktop Linux VM 中的目录绑定挂载到容器中。
它不会限制将您的主机文件的绑定挂载到容器中,如 Docker Desktop 的**设置**>**资源**>**文件共享**中配置的那样。
启用 ECI 时,我可以将主机的 Docker Socket 挂载到容器中吗?
出于安全原因,ECI 默认会阻止将宿主机上的 Docker socket 绑定挂载到容器中。但是,在某些合法场景下,例如使用 Testcontainers 进行本地测试时,这是必要的。
为了支持此类用例,可以配置 ECI 以允许将 Docker socket 挂载到容器中,但这仅限于您选择的(即,受信任的)容器镜像,甚至可以限制容器可以通过 socket 发送到 Docker Engine 的命令。请参见 ECI Docker socket 挂载权限。
ECI 是否保护使用 Docker Desktop 启动的所有容器?
尚未实现。它保护用户通过 docker create
和 docker run
启动的所有容器。
在 Docker Desktop 4.30 之前,它不会隐式保护 docker build
使用 docker
构建驱动程序(默认驱动程序)使用的容器。从 Docker Desktop 4.30 开始,它会保护此类容器,但 WSL 2(Windows 宿主机)上的 Docker Desktop 除外。
请注意,从 Docker Desktop 4.19 开始,在所有受支持的平台(带有 WSL 2 或 Hyper-V 的 Windows、Mac 和 Linux)上,使用 docker-container 构建驱动程序 时,ECI 始终会保护 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 运行时创建。
禁止使用 runc
的原因是它允许用户在 Docker Desktop Linux 虚拟机上以“真 root”身份运行,从而使他们能够隐式控制虚拟机并修改 Docker Desktop 的管理配置。
ECI 与 Docker Engine 的 userns-remap 模式有何不同?
请参见 其工作原理。
ECI 与无根 Docker 有何不同?
请参见 其工作原理