--cap-drop 是实现容器最小化授权的关键手段，通过运行时剥离 Linux 能力（如 SYS_ADMIN、NET_RAW 等）降低攻击面；需结合 --user、--read-only 等协同加固，并持续验证收敛能力集。
通过 --cap-drop 参数限制容器能力（capabilities），是实现容器生命周期最小化授权的关键手段之一。它不依赖外部策略引擎，直接在运行时剥离 linux 内核赋予进程的特权能力，从源头降低攻击面——比如阻止容器内进程挂载文件系统、修改网络配置或执行 raw socket 操作。
明确哪些能力是容器真正需要的
默认情况下，Docker 为容器授予了约 40 项 capabilities（如 CAP_NET_RAW、CAP_SYS_ADMIN 等）。但绝大多数应用仅需极少数能力即可正常运行：
- Web 服务（Nginx/HTTP Server）：通常只需
CAP_CHOWN、CAP_SETUIDS、CAP_SETGIDS（用于切换用户/组），其余可全部移除 - 数据库（PostgreSQL/MySQL）：一般不需要
CAP_NET_RAW或CAP_SYS_MODULE，禁用后不影响核心功能 - 纯计算型任务（如 Python 脚本处理 JSON）：可能完全不需要任何 capability，可使用
--cap-drop=ALL
用 --cap-drop 精确剔除高风险能力
优先移除以下常被滥用、且多数应用无依赖的能力：
-
CAP_SYS_ADMIN：最危险的能力，涵盖挂载、卸载、命名空间管理等，90% 的容器无需此权限 -
CAP_NET_RAW：允许构造原始网络包，常被用于端口扫描或协议混淆，普通服务应禁用 -
CAP_SYS_MODULE：加载/卸载内核模块，容器中几乎从不使用，必须禁用 -
CAP_AUDIT_WRITE：写入内核审计日志，非安全审计类容器无需开启
示例命令：
docker run --cap-drop=SYS_ADMIN --cap-drop=NET_RAW --cap-drop=MODULE --cap-drop=AUDIT_WRITE -d nginx:alpine
结合 --user 和 --read-only 进一步收紧权限
--cap-drop 需与其他最小权限机制协同使用，才能覆盖容器全生命周期：
- 用
--user指定非 root 用户运行（如--user 1001:1001），避免因 UID=0 触发隐式能力提升 - 加
--read-only挂载根文件系统为只读，防止恶意写入二进制或配置文件 - 配合
--tmpfs /run --tmpfs /tmp提供必要可写临时路径，替代全局可写层 - 若需特定能力（如时间同步），显式添加
--cap-add=SYS_TIME，而非保留默认全集
验证与持续收敛能力集
运行后应主动验证能力裁剪是否影响功能，并建立收敛机制：
- 进入容器检查当前能力：
capsh --print | grep "Current" - 观察日志或错误（如
Operation not permitted），定位缺失能力，按需精准回加，而非放宽整体策略 - 将稳定后的
--cap-drop列表纳入 CI/CD 流水线镜像构建阶段，作为准入检查项 - 对长期运行的容器，定期用
docker inspect审计其启动参数，确保未被绕过
