按需补最小能力
Linux 能力把 root 的特权拆成一批细粒度单元，容器默认保留其中一小组。当业务确实需要额外权限时，正确做法是先 --cap-drop=ALL 清空，再按需 --cap-add 补上必要的那一两项，比保留整套默认能力再想办法收紧可控得多。核对是否真的到位，看容器内 /proc/self/status 里的 CapEff 取值即可。
基本信息
| 语法 | --cap-drop=ALL --cap-add=能力名（可重复） |
|---|---|
| 验证位置 | 容器内 grep Cap /proc/self/status 的 CapEff |
| 常见能力 | NET_BIND_SERVICE / CHOWN / SETUID / SETGID / SYS_TIME |
| 默认能力集 | 随容器运行时版本有差异，以实际取值为准 |
典型使用场景
- 非 root 进程监听低端口：只补 NET_BIND_SERVICE，不用整块特权
- 启动脚本调整数据目录属主：补 CHOWN 与 SETUID/SETGID
- 时间敏感服务：需要设置系统时间时补 SYS_TIME
- 网络诊断容器：需要改路由或抓包时补 NET_ADMIN
- 安全基线落地：把能力集写进编排文件并纳入核对清单
补能力与核对
补能力与核对
# 清空默认能力，只补绑定低端口这一项
docker run --rm --cap-drop=ALL --cap-add=NET_BIND_SERVICE alpine sh -c 'grep CapEff /proc/self/status'
# 启动脚本需要改属主与降权的场景
docker run -d --name app --cap-drop=ALL --cap-add=CHOWN --cap-add=SETGID --cap-add=SETUID app/base:2.0
# 核对容器实际持有的能力
docker inspect -f '{{json .HostConfig.CapAdd}} {{json .HostConfig.CapDrop}}' app常用能力与用途
| 能力 | 允许的动作 | 典型场景 |
|---|---|---|
| NET_BIND_SERVICE | 绑定 1024 以下端口 | 非 root 进程监听 80 与 443 |
| CHOWN | 修改文件属主 | 启动时调整数据目录权限 |
| SETUID 与 SETGID | 切换进程身份 | 以 root 启动后降权运行 |
| SYS_TIME | 设置系统时间 | 时间同步与对时工具 |
| NET_ADMIN | 网络配置与抓包 | 诊断容器与网络工具 |
能力在容器启动时确定，运行中修改需要重建容器；编排文件里改动后要确认实际创建出来的容器才带上新配置。
能力只覆盖内核权限面，服务自身的认证、注入与配置错误仍需按应用层方向治理。
运行日志里出现 operation not permitted 时，先看缺的是文件系统权限还是某项能力：前者的报错常指向具体路径，后者多发生在绑定低端口、改属主、设置时间这类动作上。