mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-10-20 09:46:54 +00:00
yeasy
ac5ec03ab5
安全（四条，前三条都是书自己打自己）：
- 18.5 的自定义 seccomp 示例用 `"defaultAction": "SCMP_ACT_ALLOW"` 写了一个
blocklist。但 `--security-opt seccomp=<file>` 是**整体替换**默认 profile
而非叠加（官方 seccomp 文档：容器"uses the default profile unless you
override it"），而默认 profile 恰恰是 deny-by-default 的 allowlist——本节
第 11 行自己就这么写的。净效果是：挡住了 chmod，却把默认拦下的那 ~44 个
高危调用（unshare / keyctl / add_key / bpf / perf_event_open / init_module
/ reboot 等）全部放行，**比不加这个参数更危险**，而读者会以为自己加固了。
改为从官方 default.json 派生，并在示例前置醒目警告。
- 7.6 把 `docker run -e DB_PASSWORD=xxx` 标成「✅ 正确」。它只是把泄漏路径
从镜像换到了别处：进 shell history、进宿主机进程 argv（同机任何用户 ps
可见）、并永久固化在 `docker inspect` 的 Config.Env 里。而本书 11.8:102
明写「不要把数据库密码写入 compose.yaml、.env、**命令行** 或 Git」，
16.3:251 也要求「避免把真实口令写入命令历史」。改为标注 -e 的泄漏面，
并给出 --env-file / Compose secrets 的正确做法。
- 6.2 教读者起一个**无认证、无 TLS** 的 registry，且引导把它绑到内网地址、
开 insecure-registries，全节零安全提示。同网段任意主机可匿名 push，即
镜像投毒。而 18.3:17 用最强语气写着「绝不能在没有任何安全控制的情况下
强行开启」。示例改为绑 127.0.0.1，并在两处补上风险说明与指向 6.3 的出口。
- 18.6 的 CI 示例里，Trivy 那条注释写着「务必使用不可变的 commit SHA 引用，
而非可变标签」（引的是 2026-03-19 Trivy Actions 76 个 tag 被劫持事件），
可同一 workflow 里另外九条 uses 全是可变标签，包括持有凭据的
docker/login-action。补一段说明点破这一点。（本仓库自己的
.github/workflows/ 确实全部按 SHA 钉死，已实测确认后才写进书里。）
版本时效（对 GitHub releases / endoflife.date / docs.docker.com 逐条核实）：
- 5.1 与 6.3 说 `ubuntu:24.04`「是最新 LTS」——最新 LTS 已是 26.04
（2026-04-23 发布）；而本书 3.1 早就列出了 26.04，属书内不一致。更糟的是
5.1 建议可替换为 `ubuntu:20.04`，而 3.1:33 正警告 20.04 已不在支持列表。
- 3.1 的支持列表里的 Ubuntu 25.10 已被 Docker 官方安装文档移除（该版本本身
也已于 2026-07-01 EOL），删去。
- 4.6 拿 `alpine:3.20` 当"锁定版本以确保可重现性"的范例，而 3.20 已于
2026-04 EOL；改为 3.24。
- 3.2 的「Debian Bullseye 11 将于 2026 年 8 月底结束长期支持」时态已过期。
- kind v0.31.0 → v0.33.0（落后两个小版本）；etcd v3.5.29 → v3.5.33。
- 10_buildx/README 推荐「Docker v28 及以上」，而紧接着的段落就在用
「自 Docker Engine 29 起」立论；改为 v29。
第十八章 安全
容器安全是生产环境部署的核心考量。本章介绍 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 |
| 网络隔离 | 检查网络配置 |
| 敏感信息 | 确认无硬编码密码 |