mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-10-19 09:36:13 +00:00
yeasy
90536e9b85
- 18.1 完整演示了如何开启 `userns-remap`，全程没有任何代价提示。但官方文档 明写「The containerd image store is not available when using user namespace remapping」，而本书基线是 Docker Engine v29.x——该版本新装默认就是 containerd image store，12.4 节还把它标为「强烈推荐（现代默认）」。照 18.1 做完，读者会在毫不知情的情况下退回旧存储后端，失去 OCI image index、多架构 镜像与构建溯源。补上这条互斥关系并交叉引用 12.4。 - 5 章说「生产环境建议指定确切版本号（如 nginx:1.28.0）而非仅大版本号」， 7 章说「使用主或次版本号而非完整版本号（patch）」并把 patch 版本列入 「避免」。两条都以全书建议的口吻写成，方向正好相反。它们其实面向不同环节： Dockerfile 的**基础镜像**用主/次版本号，才能在重新构建时自动带上安全补丁； **部署**一个服务镜像则应钉死确切版本，让部署可复现、升级是显式动作。 两处各补一句限定范围并互相指引，而不是删掉其中一条。
第十八章 安全
容器安全是生产环境部署的核心考量。本章介绍 Docker 的安全机制和最佳实践。
容器安全的本质
核心问题：容器共享宿主机内核，隔离性弱于虚拟机。如何在便利性和安全性之间取得平衡？
flowchart LR
subgraph VM ["虚拟机安全模型：<br/>完全隔离（性能损耗）"]
direction TB
Guest["Guest OS"]
Hyper["Hypervisor<br/><-- 隔离边界"]
Host["Host OS"]
Guest --> Hyper --> Host
end
subgraph Container ["容器安全模型：<br/>进程隔离（轻量但需加固）"]
direction TB
Proc["容器进程<br/>(共享内核)"]
Mech["Namespace <-- 隔离边界<br/>Cgroups<br/>Capabilities"]
Proc --> Mech
end
本章内容
本章涵盖 Docker 安全的多个层面，从内核隔离机制到运行时防护和供应链安全。
-
- 命名空间的安全意义、User Namespace 与提权防护。
-
- 通过 Cgroups 限制容器资源使用，防止资源耗尽攻击。
-
- Docker 守护进程的安全配置与网络访问控制。
-
- Linux Capabilities 的细粒度权限控制。
-
- 镜像安全（漏洞扫描、签名验证）、运行时安全（非 root 运行、只读文件系统、Seccomp、AppArmor）、Dockerfile 安全实践、软件供应链安全（SBOM、SLSA）。
-
- 容器镜像的安全扫描、漏洞检测与签名验证。
安全扫描清单
部署前检查：
| 检查项 | 命令/方法 |
|---|---|
| 漏洞扫描 | docker scout cves 或 trivy |
| 非 root 运行 | 检查 Dockerfile 中的 USER |
| 资源限制 | 检查 -m, --cpus 参数 |
| 只读文件系统 | 检查 --read-only |
| 无特权模式 | 确认没有 --privileged |
| 最小能力 | 检查 --cap-drop=all |
| 网络隔离 | 检查网络配置 |
| 敏感信息 | 确认无硬编码密码 |