Docker怎么在启动时使用--cap-drop彻底剥离容器的特权-LINUX-PHP中文网

--cap-drop=all 会移除所有linux能力，导致依赖特权操作的应用启动失败；必须配合--cap-add显式添加所需能力（如net_bind_service），并结合strace或capsh --print验证实际需求。

docker怎么在启动时使用--cap-drop彻底剥离容器的特权

--cap-drop=ALL 是最直接、最彻底的剥离方式，但它不是“一加就完事”的开关，而是需要配合验证和补漏的起点。

为什么 `--cap-drop=ALL` 后应用大概率直接报错？

因为 Linux 能力不是可选功能，而是内核对系统调用的硬性检查。一旦进程缺失某个能力，哪怕只是调用 setuid()、chown() 或尝试绑定 80 端口，就会收到 Operation not permitted。常见现象包括：

Java 应用启动失败，卡在 java.security.AccessControlException 或 java.net.BindException: Permission denied
Node.js 的 process.setuid() 抛 EPERM
Nginx 启动时提示 bind() to 0.0.0.0:80 failed (13: Permission denied)
Python 的 os.chown() 或 os.setgroups() 失败

必须搭配 `--cap-add` 才能跑起来，但别乱加

--cap-drop=ALL 的意义在于强制你“显式声明依赖”，而不是靠默认白名单蒙混过关。加哪些，取决于你的应用真实行为，不是凭经验猜：

监听 80/443 端口 → 只加 --cap-add=NET_BIND_SERVICE，不是 NET_ADMIN 或 ALL
需要修改文件属主（如日志轮转）→ 按需加 --cap-add=CHOWN，而非 DAC_OVERRIDE
调用 clock_settime() 修改系统时间 → 加 --cap-add=SYS_TIME，极少见，慎用
需要 strace 调试或监控子进程 → 加 --cap-add=SYS_PTRACE，但生产环境应禁用
绝对不要加 SYS_ADMIN、SYS_MODULE、NET_ADMIN（除非你真在容器里做网络设备管理）

怎么确认到底缺哪个能力？

别靠文档猜，用 strace 直接看系统调用失败点：

docker run --cap-drop=ALL -it alpine sh -c "strace -e trace=setuid,setgid,chown,bind nginx -t 2>&1 | grep -E '(EACCES|EPERM)'"

输出中出现 setuid(0) = -1 EPERM (Operation not permitted) 就说明需要 CAP_SETUIDS；出现 bind(3, ..., 16) = -1 EACCES (Permission denied) 则对应 NET_BIND_SERVICE（注意：不是所有 bind 失败都因缺能力，也可能是端口被占或地址不可用）。

docker-container-rerun-all

顺序检查并可选更新所有已在长期记忆中记录了固定重建命令的 docker run 容器。使用场景：用户...

下载

更轻量的方式是进容器后运行：capsh --print，它会列出当前进程实际拥有的能力集合，帮你核对是否遗漏或误加。

Kubernetes 中等效写法容易漏掉关键字段

YAML 里不能只写 capabilities.add，drop 必须显式设为 ["ALL"]，否则默认保留 Docker 守护进程的白名单（约 14 项）：

securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE", "CHOWN"]
  runAsUser: 1001
  runAsGroup: 1001
  allowPrivilegeEscalation: false

注意：allowPrivilegeEscalation: false 是配套项，防止进程通过 execve() 启动新进程时重新获取能力；runAsUser 非 root 是另一层防护，两者不互斥，建议共用。

真正难的是判断“这个能力是不是真的被用了”——很多老代码会尝试调用 setuid() 即使 uid 已是目标值，或者反复 chown 同一个文件。这种冗余调用在 --cap-drop=ALL 下会暴露，但修复它比硬加能力更安全。