--cap-add仅在容器启动时赋予初始能力，无法实现生命周期动态管控；需结合多阶段脚本、非root用户、sidecar、seccomp等机制分阶段授权与降权。
直接通过 --cap-add 给容器添加 linux 能力（capabilities），不能控制“生命周期”，它只影响容器启动时的初始权限状态。能力是进程级的内核权限标记，一旦容器进程获得某项能力，就全程持有，不会随时间或事件自动增减。所谓“细粒度生命周期赋权”，实际需结合其他机制协同实现。
理解 --cap-add 的作用边界
--cap-add 仅在容器初始化阶段（即 docker run 启动时）将指定能力赋予容器主进程（PID 1）。它不提供运行时动态加/删能力的能力，也不感知容器内服务的启动、健康检查、升级或退出等生命周期阶段。
- 例如：
docker run --cap-add=NET_ADMIN nginx→ nginx 主进程从启动起就拥有配置网络设备的权限，直到退出 - 该能力不会在 nginx reload 配置时“临时启用”，也不会在健康检查失败后“自动回收”
- Linux 内核不支持对已运行进程动态修改 capability 集合（除非用
libcap工具在容器内手动操作，但 Docker 不管理这类行为）
真正实现生命周期敏感的权限控制方式
若需按阶段差异化授权（如：初始化时需要 SYS_ADMIN 挂载存储，运行时降权为普通用户；升级时临时提权），应组合使用以下机制：
-
多阶段入口点（entrypoint）脚本：在容器启动脚本中分步执行特权操作，完成后主动放弃能力（如用
setcap清除二进制文件能力，或用capsh --drop=...降低当前 shell 权限） -
非 root 用户 + capabilities 补充：以低权限用户启动，仅对必要二进制文件（如
ip、mount）单独授 capability，而非整个容器进程，缩小攻击面 -
与 init 系统或 sidecar 协同：用轻量 init（如
tini）管理子进程；或部署 sidecar 容器专责特权操作（如证书轮换、网络配置），主应用容器保持无特权 -
运行时策略工具集成：配合
PodSecurityPolicy（K8s v1.21+ 已弃用）、Pod Security Admission或第三方方案（如 Kyverno、OPA Gatekeeper）在调度层校验并约束能力使用场景
典型安全实践示例
一个需要挂载 tmpfs 并运行非 root 应用的容器，可这样设计：
- 启动时用
--cap-add=SYS_ADMIN，但入口脚本立即执行挂载，随后exec切换到非 root 用户运行主程序 - 关键工具（如
/usr/local/bin/config-reloader）单独设置cap_net_admin+ep，主进程不继承该能力 - 通过
--read-only和--tmpfs限制文件系统权限，避免依赖能力做越权写入
替代方案：比 cap-add 更精细的权限模型
当 --cap-add 显得过于宽泛时，优先考虑更底层或更结构化的权限控制：
-
Seccomp BPF 过滤器：禁止特定系统调用（如
mount、clone），比开放SYS_ADMIN更精确 - AppArmor / SELinux 策略：定义进程可访问的路径、网络端口、文件类型等，与生命周期阶段解耦但管控粒度更细
- user namespaces 映射：让容器内 root（UID 0）映射到宿主机非特权 UID，从根本上限制能力的实际效力
Cap-add 是启动时的权限开关，不是生命周期控制器。要实现按阶段赋权，核心思路是：用脚本编排权限获取与释放时机，用最小能力集 + 辅助机制（seccomp/apparmor/userns）补足管控缺口，把“何时需要权”和“如何安全用权”拆开设计。
