限制
ECI 对 WSL 的支持
在 Docker Desktop 4.20 之前，只有当 Docker Desktop 配置为使用 Hyper-V 创建 Docker Desktop Linux VM 时，Windows 主机上的增强容器隔离 (ECI) 才受支持。当 Docker Desktop 配置为使用 Windows Subsystem for Linux（又名 WSL）时，ECI 不受支持。
从 Docker Desktop 4.20 开始，当 Docker Desktop 配置为使用 Hyper-V 或 WSL 2 时，ECI 受支持。
注意
Docker Desktop 需要 WSL 2 版本 1.1.3.0 或更高版本。要获取主机上的当前 WSL 版本，请键入
wsl --version。如果命令失败或返回的版本号早于 1.1.3.0，请通过在 Windows 命令或 PowerShell 终端中键入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 无法保证内核级别配置的完整性。 |
总的来说，与 WSL 2 相比，使用 Hyper-V 的 ECI 更安全。但 WSL 2 为主机上的性能和资源利用提供了优势，它是用户在 Windows 主机上运行其喜欢的 Linux 发行版并从内部访问 Docker 的绝佳方式（请参阅 Docker Desktop 的 WSL 发行版集成功能，该功能通过仪表板的“**设置**”>“**资源**”>“**WSL 集成**”启用）。
使用“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 VM 中以 rootless 方式运行），除了当 Docker Desktop 配置为使用 WSL 2（在 Windows 主机上）时。我们希望在未来的 Docker Desktop 版本中改进这一点。
请注意，使用 docker-container 驱动程序的 docker build 命令始终受 ECI 保护（即，构建在 rootless Docker 容器中运行）。这从 Docker Desktop 4.19（引入 ECI 时）开始，适用于支持 Docker Desktop 的所有平台（带有 WSL 或 Hyper-V 的 Windows、Mac 和 Linux）。
Docker Build 和 Buildx 存在一些限制
启用 ECI 后，不允许使用 Docker build --network=host 和 Docker Buildx 授权（network.host、security.insecure）。需要这些的构建将无法正常工作。
Kubernetes Pod 尚未受保护
Kubernetes Pod 尚未受 ECI 保护。恶意或特权 Pod 可能会破坏 Docker Desktop Linux VM 并绕过安全控制。
扩展容器尚未受保护
扩展容器也尚未受 ECI 保护。请确保您的扩展容器来自受信任的实体，以避免出现问题。
Docker Desktop 开发环境尚未受保护
由 Docker Desktop Dev Environments 功能启动的容器也尚未受到保护。我们希望在未来的 Docker Desktop 版本中改进这一点。
Docker Debug 容器尚未受保护
Docker Debug 容器尚未受 ECI 保护。我们希望在未来的 Docker Desktop 版本中改进这一点。
生产环境中的使用
总的来说，用户在 Docker Desktop 中运行启用 ECI 的容器（使用 Sysbox 运行时）与在生产环境中通过标准 OCI runc 运行时运行同一个容器之间不应该存在差异。
但是，在某些情况下，通常是在容器中运行高级或特权工作负载时，用户可能会遇到一些差异。特别是，容器可以在启用 ECI 的情况下运行，但在 runc 下无法运行，反之亦然。