Docker 的 --cap-add/--cap-drop 仅作用于容器主进程且不可动态修改，需通过清空默认能力、绑定能力到特定二进制、入口脚本分阶段提权降权、sidecar 分离特权任务等组合策略实现细粒度权限控制。
直接用 --cap-add 或 --cap-drop 只能控制容器启动时主进程（PID 1）的初始能力集，不能对“特定进程”动态赋权或裁剪。Linux 内核本身不支持运行时修改已存在进程的能力集合，Docker 也不提供进程级能力隔离。所谓“细粒度裁剪或赋予特定进程”，实际要靠组合策略实现：在容器内区分执行主体、分阶段控制、缩小能力作用范围。
从默认能力起步，先清空再按需添加
Docker 默认保留约 14 个 capability（如 CAP_CHOWN、CAP_NET_BIND_SERVICE），但它们都落在容器主进程上。安全做法不是删掉几个高危项，而是从零开始重建权限模型：
- 用
--cap-drop=ALL彻底清空所有默认能力 - 只加真正需要的能力，例如 Web 服务只需
--cap-add=NET_BIND_SERVICE - 如果应用内部有多个子进程（如 nginx worker、健康检查脚本），需确认哪些二进制文件真正依赖某能力——不是整个容器都需要，而是某个命令需要
- 避免为整个容器加
SYS_ADMIN，除非你明确知道每个子进程都会用到它
让能力落在具体可执行文件上，而非整个容器
容器主进程拥有能力 ≠ 所有子进程自动继承。你可以把能力绑定到特定二进制，让普通用户也能安全调用：
- 以非 root 用户启动容器（
--user 1001:1001） - 在镜像构建阶段给必要工具授能力，例如：
RUN setcap cap_net_bind_service+ep /usr/local/bin/myserver - 这样
myserver即使由普通用户运行，也能绑定 80 端口；其他进程（如日志轮转脚本）则完全无此能力 - 用
getcap /usr/local/bin/myserver验证是否生效
用入口脚本分阶段提权与降权
很多场景需要“初始化时有特权，运行后降权”——比如挂载配置卷、生成证书后再切换为低权限用户：
- 写一个
entrypoint.sh，开头以 root 运行，完成挂载、chown、证书生成等操作 - 完成后执行
exec capsh --drop=all --user=1001 -- "$@"，把后续进程彻底剥离所有能力，并切换用户 - 这样主服务进程（如 nginx worker）既没能力也没 root 权限，攻击面大幅缩小
- 避免在容器里长期保留
CAP_SYS_ADMIN或CAP_DAC_OVERRIDE
用 sidecar 或外部协调器承担特权任务
真正需要跨生命周期管理权限时，不要让主应用容器承担全部职责：
- 部署独立 sidecar 容器，专责网络配置（
--cap-add=NET_ADMIN）、密钥注入或存储挂载 - 主应用容器保持无 cap、非 root、
--cap-drop=ALL，通过本地 socket 或文件系统共享结果 - 在 Kubernetes 中，可用 initContainer 提前完成特权操作，再把成果交给 main container
- 这样能力被严格限定在最小作用域和最短生命周期内，符合最小权限原则
