限制
ECI 支持 WSL
注意
Docker Desktop 需要 WSL 2 版本 1.1.3.0 或更高版本。要获取主机上当前的 WSL 版本，请键入
wsl --version。如果命令失败或返回的版本号低于 1.1.3.0，请通过在 Windows 命令提示符或 PowerShell 终端中键入wsl --update来将 WSL 更新到最新版本。
ECI 在 WSL 上不如在 Hyper-V 上安全，因为：
虽然 WSL 上的 ECI 仍然对容器进行加固，以防止恶意工作负载轻易攻破 Docker Desktop 的 Linux 虚拟机，但 WSL 上的 ECI 无法防止 Docker Desktop 用户攻破 Docker Desktop Linux 虚拟机。此类用户可以使用
wsl -d docker-desktop命令轻易访问该虚拟机（以 root 身份），并利用该访问权限修改虚拟机内的 Docker Engine 设置。这使 Docker Desktop 用户能够控制 Docker Desktop 虚拟机，并允许他们绕过管理员通过 settings-management 功能设置的 Docker Desktop 配置。相比之下，Hyper-V 上的 ECI 不允许 Docker Desktop 用户攻破 Docker Desktop Linux 虚拟机。使用 WSL 2 时，同一 Windows 主机上的所有 WSL 2 发行版共享同一个 Linux 内核实例。因此，Docker Desktop 无法确保 Docker Desktop Linux 虚拟机中内核的完整性，因为其他 WSL 2 发行版可能会修改共享的内核设置。相比之下，使用 Hyper-V 时，Docker Desktop Linux 虚拟机拥有一个专用内核，该内核完全由 Docker Desktop 控制。
下表对此进行了总结。
| 安全功能 | WSL 上的 ECI | Hyper-V 上的 ECI | 评论 |
|---|---|---|---|
| 强安全容器 | 是 | 是 | 增加恶意容器工作负载突破 Docker Desktop Linux 虚拟机和主机的难度。 |
| Docker Desktop Linux 虚拟机受保护，禁止用户访问 | No | 是 | 在 WSL 上，用户可以直接访问 Docker Engine 或绕过 Docker Desktop 安全设置。 |
| Docker Desktop Linux 虚拟机拥有专用内核 | No | 是 | 在 WSL 上，Docker Desktop 无法保证内核级配置的完整性。 |
总体而言，在 ECI 中使用 Hyper-V 比 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 虚拟机并绕过安全控制。
作为替代方案，您可以使用 K8s.io KinD 工具 配合 ECI。在这种情况下，每个 Kubernetes 节点都在受 ECI 保护的 容器内运行，从而更有效地将 Kubernetes 集群与 底层 Docker Desktop Linux 虚拟机（及其内部的 Docker 引擎）隔离。 无需特殊配置，只需启用 ECI 并照常运行 KinD 工具即可。
扩展容器尚未受保护
扩展容器目前也尚未受到 ECI 的保护。请确保您的扩展容器来自可信实体，以避免出现问题。
Docker Desktop 开发环境尚未受到保护
由 Docker Desktop 开发环境功能启动的容器尚未受到保护。
Docker Debug 容器尚未受保护
Docker Debug 容器 尚未受到 ECI 的保护。
不支持原生 Windows 容器
ECI 仅在 Docker Desktop 处于 Linux 容器模式（默认且最常用的模式）时有效。当 Docker Desktop 配置为原生 Windows 容器模式时，不支持 ECI（即当 Docker Desktop 从默认的 Linux 模式切换为原生 Windows 模式时，不支持在 Windows 主机上运行）。
在生产环境中使用
通常情况下，用户不应感觉到在启用了 ECI 的 Docker Desktop（使用 Sysbox 运行时）中运行容器，与在生产环境中通过标准 OCI runc 运行时运行同一容器之间有什么区别。
但在某些情况下，通常是在容器中运行高级或特权工作负载时，用户可能会遇到一些差异。具体来说，容器可能在 ECI 下运行，但无法在 runc 下运行，反之亦然。