限制
WSL 对 ECI 的支持
注意
Docker Desktop 需要 WSL 2 版本 1.1.3.0 或更高版本。要获取主机上当前安装的 WSL 版本，请在 Windows 命令提示符或 PowerShell 终端中输入
wsl --version。如果命令失败或返回的版本号低于 1.1.3.0，请通过输入wsl --update将 WSL 更新到最新版本。
WSL 上的 ECI 不如 Hyper-V 上的 ECI 安全，原因如下：
虽然 WSL 上的 ECI 仍会强化容器，使恶意工作负载不易突破 Docker Desktop 的 Linux VM，但 WSL 上的 ECI 无法阻止 Docker Desktop 用户突破 Docker Desktop Linux VM。此类用户可以使用
wsl -d docker-desktop命令（以 root 身份）轻松访问该 VM，并利用此访问权限修改 VM 内的 Docker Engine 设置。这使得 Docker Desktop 用户可以控制 Docker Desktop VM，并绕过管理员通过settings-management 功能设置的 Docker Desktop 配置。相比之下，Hyper-V 上的 ECI 不允许 Docker Desktop 用户突破 Docker Desktop Linux VM。使用 WSL 2 时，同一 Windows 主机上的所有 WSL 2 分发版共享相同的 Linux 内核实例。因此，Docker Desktop 无法确保 Docker Desktop Linux VM 中内核的完整性，因为另一个 WSL 2 分发版可能会修改共享内核设置。相比之下，使用 Hyper-V 时，Docker Desktop Linux VM 拥有一个专用内核，完全由 Docker Desktop 控制。
下表总结了这一点。
| 安全特性 | WSL 上的 ECI | Hyper-V 上的 ECI | 备注 |
|---|---|---|---|
| 强力保护容器 | 是 | 是 | 使恶意容器工作负载更难突破 Docker Desktop Linux VM 和宿主。 |
| Docker Desktop Linux VM 免受用户访问 | 否 | 是 | 在 WSL 上，用户可以直接访问 Docker Engine 或绕过 Docker Desktop 安全设置。 |
| Docker Desktop Linux VM 拥有专用内核 | 否 | 是 | 在 WSL 上，Docker Desktop 无法保证内核级配置的完整性。 |
总的来说，结合 Hyper-V 使用 ECI 比结合 WSL 2 使用更安全。但是 WSL 2 在主机性能和资源利用方面具有优势，并且是用户在 Windows 主机上运行喜爱的 Linux 分发版并从其中访问 Docker 的绝佳方式。
使用“docker”驱动程序的 Docker 构建的 ECI 保护
在 Docker Desktop 4.30 之前，使用 buildx docker 驱动程序（默认）的 docker build 命令不受 ECI 保护，换句话说，构建在 Docker Desktop VM 内以 root 身份运行。
从 Docker Desktop 4.30 开始，使用 buildx docker 驱动程序的 docker build 命令受到 ECI 保护，除非 Docker Desktop 配置为使用 WSL 2（在 Windows 主机上）。
请注意，使用 docker-container 驱动程序的 docker build 命令始终受到 ECI 保护。
Docker Build 和 Buildx 的一些限制
启用 ECI 后，不允许使用 Docker build --network=host 和 Docker Buildx 特权 (network.host, security.insecure)。需要这些的构建将无法正常工作。
Kubernetes Pod 尚不受保护
使用 Docker Desktop 集成的 Kubernetes 时，Pod 尚不受 ECI 保护。因此，恶意或特权 Pod 可能会危及 Docker Desktop Linux VM 并绕过安全控制。
作为替代方案，您可以结合 ECI 使用 K8s.io KinD 工具。在这种情况下，每个 Kubernetes 节点都在 ECI 保护的容器内运行，从而将 Kubernetes 集群更强力地与底层 Docker Desktop Linux VM（及其中的 Docker Engine）隔离开来。无需特殊设置，只需启用 ECI 并像往常一样运行 KinD 工具即可。
扩展容器尚不受保护
扩展容器目前也不受 ECI 保护。请确保您的扩展容器来自受信任的实体，以避免问题。
Docker Desktop 开发环境尚不受保护
Docker Desktop 开发环境功能启动的容器尚不受保护。
Docker Debug 容器尚不受 ECI 保护。
Docker Debug 容器尚不受 ECI 保护。
不支持原生 Windows 容器
ECI 仅在 Docker Desktop 处于 Linux 容器模式（默认、最常用模式）时有效。当 Docker Desktop 配置为原生 Windows 容器模式时（即，在 Windows 主机上，当 Docker Desktop 从其默认的 Linux 模式切换到原生 Windows 模式时），不支持 ECI。
在生产环境中使用
通常，用户在使用启用 ECI 的 Docker Desktop（使用 Sysbox 运行时）运行容器与通过标准 OCI runc 运行时在生产环境中运行同一容器时，不应感受到差异。
然而，在某些情况下，特别是在容器中运行高级或特权工作负载时，用户可能会遇到一些差异。尤其是，容器可能在 ECI 下运行良好，但在 runc 下不行，反之亦然。