增強型容器隔離的限制
增強型容器隔離 (ECI) 具有一些特定於平台的限制與功能約束。了解這些限制有助於規劃您的安全性策略並設定合理的預期。
WSL 2 安全性考量
注意Docker Desktop 需要 WSL 2 2.1.5 或更新版本。請使用
wsl --version檢查您的版本，若有需要，請使用wsl --update進行更新。
根據您的 Windows 後端設定，增強型容器隔離提供不同的安全性層級。
下表比較了 ECI 在 WSL 2 與 Hyper-V 上的差異
| 安全性功能 | 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 的安全性漏洞包括
- 直接 VM 存取：使用者可以透過直接存取 VM 來繞過 Docker Desktop 安全性：
wsl -d docker-desktop。這使使用者能夠取得 root 權限來修改 Docker Engine 設定並繞過設定管理 (Settings Management) 配置。 - 共享核心漏洞：所有 WSL 2 發行版共享同一個 Linux 核心實例。其他 WSL 發行版可以修改影響 Docker Desktop 安全性的核心設定。
建議
請使用 Hyper-V 後端以達到最高安全性。WSL 2 提供了更好的效能與資源利用率，但安全隔離性較低。
不支援 Windows 容器
ECI 僅適用於 Linux 容器（Docker Desktop 的預設模式）。不支援原生 Windows 容器模式。
Docker 建置保護效果不一
Docker Build 的保護效果取決於驅動程式與 Docker Desktop 版本
| 建置驅動程式 (Build driver) | 保護狀態 | 版本需求 |
|---|---|---|
docker (預設) | 已保護 | Docker Desktop 4.30 及更新版本（WSL 2 除外） |
docker (舊版) | 未受保護 | 4.30 以前的 Docker Desktop 版本 |
docker-container | 始終受保護 | 所有 Docker Desktop 版本 |
以下 Docker Build 功能不適用於 ECI
docker build --network=host- Docker Buildx 授權：
network.host,security.insecure
建議
針對需要這些功能的建置，請使用 docker-container 建置驅動程式
$ docker buildx create --driver docker-container --use
$ docker buildx build --network=host .
Docker Desktop Kubernetes 未受保護
整合式的 Kubernetes 功能無法受惠於 ECI 保護。惡意或具備特權的 Pod 可能會破壞 Docker Desktop VM 並繞過安全性控制。
建議
若要使用 ECI 保護的 Kubernetes，請使用 Docker 中的 Kubernetes (KinD)
$ kind create cluster
啟用 ECI 後，每個 Kubernetes 節點都會在受 ECI 保護的容器中執行，從而提供與 Docker Desktop VM 更強的隔離性。
未受保護的容器類型
這些容器類型目前無法受惠於 ECI 保護
- Docker 擴充功能 (Extensions)：擴充功能容器在執行時沒有 ECI 保護
- Docker Debug：Docker Debug 容器會繞過 ECI 限制
- Kubernetes Pods：當使用 Docker Desktop 整合式 Kubernetes 時
建議
請僅使用來自受信任來源的擴充功能，並避免在安全性敏感的環境中使用 Docker Debug。
全域指令限制
指令清單適用於所有獲准掛載 Docker socket 的容器。您無法針對不同的容器映像檔設定不同的指令限制。
不支援僅限本機的映像檔
除非符合下列條件，否則您無法允許任意的本機映像檔（不在登錄檔中的映像檔）掛載 Docker socket：
- 衍生自獲准的基礎映像檔（需設定
allowDerivedImages: true） - 使用萬用字元允許清單 (
"*", Docker Desktop 4.36 及更新版本)
不支援的 Docker 指令
這些 Docker 指令目前尚未支援指令清單限制
compose：Docker Compose 指令dev：開發環境指令extension：Docker 擴充功能管理feedback：提交 Docker 回饋init：Docker 初始化指令manifest：映像檔清單 (manifest) 管理plugin：外掛程式管理sbom：軟體物料清單 (Software Bill of Materials)scout：Docker Scout 指令trust：映像檔信任管理
效能考量
衍生映像檔的影響
啟用 allowDerivedImages: true 會因為映像檔驗證，導致容器啟動時間增加約 1 秒。
登錄檔依賴性
- Docker Desktop 會定期從登錄檔抓取映像檔摘要 (digest) 以進行驗證
- 初次啟動容器時，需要存取登錄檔以驗證獲准的映像檔
- 網路連線問題可能會導致容器啟動延遲
映像檔摘要 (digest) 驗證
當登錄檔中的獲准映像檔更新時，本機容器可能會意外遭到阻擋，直到您重新整理本機映像檔為止
$ docker image rm <image>
$ docker pull <image>
版本相容性
ECI 功能是在不同版本的 Docker Desktop 中陸續引入的
- Docker Desktop 4.36 及更新版本：支援萬用字元允許清單 (
"*") 與改良的衍生映像檔處理 - Docker Desktop 4.34 及更新版本：支援衍生映像檔 (
allowDerivedImages) - Docker Desktop 4.30 及更新版本：預設驅動程式下的 Docker Build 保護（WSL 2 除外）
- Docker Desktop 4.13 及更新版本：核心 ECI 功能
欲了解最新的功能可用性，請使用最新的 Docker Desktop 版本。
正式環境相容性
容器行為差異
大多數容器在有無 ECI 的情況下執行結果相同。然而，某些進階工作負載的行為可能會有所不同
- 需要載入核心模組的容器
- 會修改全域核心設定的工作負載 (BPF, sysctl)
- 預期特定權限提升行為的應用程式
- 需要直接存取硬體裝置的工具
在正式部署前，請先在開發環境中使用 ECI 測試進階工作負載，以確保相容性。
執行階段考量
使用 Sysbox 執行階段 (配合 ECI) 的容器在正式環境中，可能與標準 OCI runc 執行階段有細微差異。這些差異通常僅影響特權操作或系統層級操作。