最有效起点是--cap-drop=all清空所有默认能力再按需加白，因其强制归零、规避默认冗余授权，并需协同--user、--read-only、no-new-privileges等实现纵深防御。
直接用 --cap-drop=all 清空所有默认能力，再按需加回真正需要的几个，是打造高安全等级容器最有效的起点。这不是“删掉多余项”，而是从零开始构建权限边界——避免因 docker 默认能力变更、镜像升级或隐式继承带来的意外风险。
先清零：--cap-drop=ALL 是安全基线
Docker 默认保留约 14 个 capability（如 CAP_CHOWN、CAP_NET_BIND_SERVICE），看似克制，但对多数应用仍是过度授权。--cap-drop=ALL 强制归零，让容器进程在启动时几乎无法执行任何特权操作，连 chown、ping、修改时间都会失败——这正是你想要的“默认拒绝”状态。
- 它会覆盖镜像中 USER 或 Dockerfile 中的默认能力设置
- 即使后续 --cap-add 漏掉某个依赖能力（比如 NET_BIND_SERVICE 需要 DAC_OVERRIDE 配合），容器也会明确报错，便于定位
- 适合金融、政务、API 网关等对权限敏感的关键服务
再加白：只添加真实运行所必需的能力
加白不是凭经验猜，而是依据应用行为精准补充。常见组合示例：
- Web 服务监听 80 端口：仅需 --cap-add=NET_BIND_SERVICE（不用开 CAP_SYS_ADMIN）
- 日志轮转或属主调整：补 --cap-add=CHOWN 和/或 DAC_OVERRIDE
- 内存锁定（如 Redis）：加 --cap-add=IPC_LOCK
- 精确控制时间（极少见）：单独加 --cap-add=SYS_TIME，而非混在一堆能力里
不推荐 --cap-add=ALL；也不建议保留默认能力再逐个 --cap-drop，容易遗漏。
验证是否真的精简到位
容器启动后，进容器执行：
capsh --print
查看 CapEff 行（有效能力列表），确认只有你显式添加的那几项。也可查：
cat /proc/1/status | grep CapEff
输出是十六进制，可用 capsh 解码比对。若看到 CAP_SYS_ADMIN、CAP_DAC_OVERRIDE、CAP_SETUIDS 等未声明的能力，说明配置没生效或被其他机制绕过。
配合其他机制形成纵深防御
Capability 控制的是内核调用权限，单靠它不够。必须叠加：
- --user 1001:1001：强制非 root 用户运行，即便有 SETUID 能力也无法提权到 UID 0
- --read-only 或 --tmpfs /run:rw,size=64m：根文件系统只读，仅开放必要可写路径
- --security-opt no-new-privileges:true：禁止运行时通过 execve 获得新权限（阻断 setuid 二进制利用链）
- 挂载卷加 :ro 标志，防止篡改宿主机配置或日志目录
这些参数共同作用，才能让容器即使被攻破，也难以逃逸或横向移动。
