限制
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 下無法執行，反之亦然。