Docker容器安全：capability权限最小化实践指南

linux 内核把传统 root 的超级权限拆分为数十个相互独立的 capability，例如绑定低端口的 NET_BIND_SERVICE、修改文件属主的 CHOWN。Docker 默认授予容器一组相对保守的 capability，但对多数业务而言仍然偏大——权限最小化的目标，就是把这组默认授权压缩到业务真实需要的最小集合。

先划清边界：privileged 与 capability

任何 capability 调优都以禁用 --privileged 为前提。特权容器一次性获得全部 capability 和宿主机设备访问权，容器内 root 与宿主机 root 之间几乎没有边界，此时再讨论细粒度授权毫无意义。合规姿势是全面禁用 privileged 模式，仅用 capability 机制做按需授权。

落地方法：先全砍，再逐项加回

稳妥路径是先以 --cap-drop=ALL 启动，再按业务需要逐项 --cap-add，而不是在默认集合上修修补补：

docker run -d --user 10001:10001 --cap-drop=ALL --cap-add=NET_BIND_SERVICE --security-opt no-new-privileges:true --read-only registry.example.com/app@sha256:9f2c...

这一条命令同时落实了四层约束：非 root 运行、capability 最小化、no-new-privileges 阻断进程通过 setuid 类机制提权、根文件系统只读使攻击者无法落地工具。实践中的操作建议是：先在测试环境用全砍配置把服务跑起来，观察应用报什么错、实际缺什么能力，再逐项加回。一个普通的 Web 服务通常只需要一两个 capability 即可正常工作；直接照抄网上的权限清单，往往会加回一堆根本用不到的能力，反而扩大了攻击面。

在此之上，还可以叠加 Docker 默认自带的 seccomp profile，以及内存、PID 数量等资源限制，防止单个容器被攻破后耗尽宿主机资源，形成纵深防御。

最后需要把这套配置固化进 CI/CD 流水线和部署模板，让权限最小化从测评前的突击整改变成每次发布的自动过关。当测评机构问起时，能直接拿出配置记录与验证结果，这比任何口头解释都有说服力。