增强型容器隔离限制
增强型容器隔离具有一些平台特定的限制和功能约束。了解这些限制有助于您规划安全策略并设定适当的预期。
WSL 2 安全注意事项
注意Docker Desktop 需要 WSL 2 版本 2.1.5 或更高版本。使用
wsl --version检查您的版本，如有需要，使用wsl --update进行更新。
增强型容器隔离根据您的 Windows 后端配置提供不同的安全级别。
下表比较了 WSL 2 上的 ECI 和 Hyper-V 上的 ECI
| 安全功能 | WSL 上的 ECI | Hyper-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 运行时相比，可能存在细微差异。这些差异通常只影响特权或系统级操作。