增強型容器隔離限制

目錄
訂閱： 商業版
適用於： 管理員

增強型容器隔離具有一些平臺特定的限制和功能約束。瞭解這些限制有助於您規劃安全策略並設定適當的預期。

WSL 2 安全注意事項

注意

Docker Desktop 需要 WSL 2 版本 2.1.5 或更高版本。使用 wsl --version 檢查您的版本，如有需要，使用 wsl --update 進行更新。

增強型容器隔離根據您的 Windows 後端配置提供不同的安全級別。

下表比較了 WSL 2 上的 ECI 和 Hyper-V 上的 ECI

安全功能WSL 上的 ECIHyper-V 上的 ECI評論
強力安全容器是是使惡意容器工作負載更難突破 Docker Desktop Linux 虛擬機器和主機。
Docker Desktop Linux 虛擬機器受保護，防止使用者訪問否是在 WSL 上，使用者可以直接訪問 Docker 引擎或繞過 Docker Desktop 安全設定。
Docker Desktop Linux 虛擬機器具有專用核心否是在 WSL 上，Docker Desktop 無法保證核心級配置的完整性。

WSL 2 安全漏洞包括

  • 直接虛擬機器訪問：使用者可以透過直接訪問虛擬機器繞過 Docker Desktop 安全：wsl -d docker-desktop。這使得使用者擁有 root 許可權，可以修改 Docker 引擎設定並繞過設定管理配置。
  • 共享核心漏洞：所有 WSL 2 發行版共享相同的 Linux 核心例項。其他 WSL 發行版可以修改影響 Docker Desktop 安全性的核心設定。

建議

使用 Hyper-V 後端以獲得最大安全性。WSL 2 提供更好的效能和資源利用率，但安全隔離性降低。

不支援 Windows 容器

ECI 僅適用於 Linux 容器（Docker Desktop 的預設模式）。不支援原生 Windows 容器模式。

Docker Build 保護有所不同

Docker Build 保護取決於驅動程式和 Docker Desktop 版本

構建驅動保護版本要求
docker（預設）受保護Docker Desktop 4.30 及更高版本（WSL 2 除外）
docker（傳統）未受保護Docker Desktop 4.30 之前的版本
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 虛擬機器並繞過安全控制。

建議

使用 Docker 中的 Kubernetes (KinD) 來實現 ECI 保護的 Kubernetes

$ kind create cluster

啟用 ECI 後，每個 Kubernetes 節點都在 ECI 保護的容器中執行，從而提供與 Docker Desktop 虛擬機器更強的隔離。

未受保護的容器型別

以下容器型別目前不受 ECI 保護

  • Docker 擴充套件：擴充套件容器在沒有 ECI 保護的情況下執行
  • Docker Debug：Docker Debug 容器繞過 ECI 限制
  • Kubernetes Pod：當使用 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：映象清單管理
  • plugin：外掛管理
  • sbom：軟體物料清單
  • scout：Docker Scout 命令
  • trust：映象信任管理

效能考量

派生映象影響

啟用 allowDerivedImages: true 會使容器啟動時間增加約 1 秒，用於映象驗證。

登錄檔依賴

  • Docker Desktop 定期從登錄檔獲取映象摘要進行驗證
  • 首次容器啟動需要訪問登錄檔來驗證允許的映象
  • 網路連線問題可能會導致容器啟動延遲

映象摘要驗證

當登錄檔中的允許映象更新時，本地容器可能會意外被阻止，直到您重新整理本地映象

$ 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 執行時相比，可能存在細微差異。這些差異通常隻影響特權或系統級操作。