1. Docker 安全基础
1.1 Docker 安全威胁模型
容器化环境引入了与传统虚拟化截然不同的攻击面。理解 Docker 的安全威胁模型是构建合规体系的第一步。威胁主要来自以下四个维度：
| 威胁维度 | 典型风险 | 影响范围 |
|---|---|---|
| 镜像供应链 | 基础镜像含漏洞、恶意植入后门、依赖库被篡改 | 所有派生容器 |
| 容器逃逸 | 内核漏洞利用、--privileged 提权、挂载敏感目录 | 宿主机及所有容器 |
| 配置漂移 | 默认开放端口、无资源限制、未设置只读根文件系统 | 单个容器或集群 |
| 运行时攻击 | 进程注入、网络嗅探、密钥泄露 | 容器内数据与业务 |
关键认知： 容器共享宿主机内核，因此内核级漏洞（如 CVE-2022-0847 Dirty Pipe）的威胁等级远高于虚拟机场景。安全基线必须从内核隔离能力开始评估。
1.2 容器与虚拟机安全对比
容器和虚拟机在隔离深度、攻击面、合规粒度上存在本质差异。下表从安全视角进行对比：
| 对比维度 | Docker 容器 | 虚拟机 |
|---|---|---|
| 隔离层级 | 进程级（Namespace + Cgroups） | 硬件级（Hypervisor + 独立内核） |
| 内核共享 | 共享宿主机内核 | 独立内核 |
| 逃逸风险 | 较高（内核漏洞直接威胁宿主机） | 较低（需突破 Hypervisor） |
| 启动时间 | 秒级 | 分钟级 |
| 镜像大小 | MB 级 | GB 级 |
| 合规审计粒度 | 需额外工具（如 Falco、Tracee） | 原生支持完整审计日志 |
实践建议： 在混合部署场景中，将高敏感工作负载（如密钥管理、支付处理）部署在虚拟机中，将无状态微服务部署在容器中，形成分层信任模型。
下图展示了容器与虚拟机在安全架构上的核心差异：
1.3 Docker 安全最佳实践概览
基于上述威胁模型与对比分析，Docker 安全最佳实践可归纳为以下六大领域。每个领域对应一组可落地的操作要点：
- 镜像安全 — 使用可信基础镜像（如 distroless、chainguard），定期扫描漏洞（Trivy / Grype），实施镜像签名（Cosign）。
- 主机加固 — 禁用非必要内核模块，开启 Seccomp / AppArmor / SELinux，限制容器 root 权限。
- 运行时保护 — 部署 Falco 实时检测异常系统调用，设置只读根文件系统（
--read-only），限制资源上限（CPU / 内存）。 - 网络隔离 — 使用自定义 bridge 网络，默认禁止容器间通信（
--icc=false），加密传输（TLS）。 - 密钥管理 — 避免环境变量传递密钥，使用 Docker Secrets 或外部密钥管理服务（Vault）。
- 合规审计 — 启用 Docker 审计日志，定期执行 CIS Docker Benchmark 检查，生成合规报告。
常见误区： 仅依赖 Docker 默认配置无法满足生产安全要求。例如，默认情况下容器以 root 运行，且未启用用户命名空间映射。必须显式配置
--userns-remap 和 USER 指令。
下图总结了 Docker 安全最佳实践的完整框架：
1.4 快速自检清单
在进入后续章节之前，建议对照以下清单评估当前环境的安全水位：
| 检查项 | 合规要求 | 验证命令 |
|---|---|---|
| 容器以非 root 运行 | Dockerfile 包含 USER 指令 |
docker inspect --format '{{.Config.User}}' <container> |
| 禁止特权模式 | --privileged 未设置 |
docker inspect --format '{{.HostConfig.Privileged}}' <container> |
| 只读根文件系统 | --read-only 已启用 |
docker inspect --format '{{.HostConfig.ReadonlyRootfs}}' <container> |
| 资源限制 | CPU / 内存上限已配置 | docker stats --no-stream |
| 镜像漏洞扫描 | 最近一次扫描无高危漏洞 | trivy image <image> |
自动化建议： 将上述检查项集成到 CI/CD 流水线中，使用
docker-bench-security 或 kube-bench 实现每日自动合规检查，避免配置漂移。