Linux能力机制遵循“先清空、再授权”的白名单逻辑，必须以--cap-drop=ALL为前提，否则默认启用的CHOWN、KILL等14个基础能力仍存在逃逸风险；仅用cap-add会导致权限叠加而非最小化。
Linux 能力机制不是“加点权限就好”，而是“先清空、再授权”的白名单逻辑。只用 cap-add 不安全，必须配合 cap-drop=ALL 才算真正落地最小权限原则。
为什么 cap-drop=ALL 是前提
Docker 默认启用约 14 个基础能力（如 CHOWN、FSETID、KILL），这些对多数业务非必需，却可能被利用绕过文件权限或篡改进程。不先清空，cap-add 只是“叠加上去”，不是“精准替换”。
- 默认启动的容器：已自带 CAP_CHOWN、CAP_KILL、CAP_SETUID 等
- 只加 NET_BIND_SERVICE：实际拥有全部默认能力 + 新增能力 → 权限膨胀
- 正确做法：--cap-drop=ALL --cap-add=NET_BIND_SERVICE --cap-add=CHOWN → 仅保留明确需要的那几个
常用 cap-add 场景与对应能力
每个能力都解决一个具体问题，别凭感觉加：
- 绑定 80/443 端口：必须 NET_BIND_SERVICE；若镜像还尝试 chown 配置目录，需额外补 CHOWN
- 同步系统时间（NTP）：加 SYS_TIME；注意宿主机应提供可信时钟源，避免时间漂移引发认证失败
-
Redis 锁定内存防 swap：加 IPC_LOCK；配合
memlockulimit 使用才生效 - 自定义网络拓扑（如创建 dummy 接口）：加 NET_ADMIN；但禁止在生产环境搭配 NET_RAW（可发原始包）
哪些 cap-add 绝对要禁用
以下能力单个启用就接近特权模式，生产环境应视为红线：
- SYS_MODULE：可加载恶意内核模块，直接获得宿主机控制权
- SYS_ADMIN：覆盖挂载、命名空间、sysctl、设备管理等 50+ 子功能，极易导致容器逃逸
-
DAC_OVERRIDE：绕过所有文件读写权限检查，
/etc/shadow、/root/.ssh全部可读 -
SYS_RAWIO：可直接访问物理设备（如
/dev/sda），破坏磁盘数据
验证与调试方法
加完能力不能只信配置，要进容器实测：
- 查看当前进程能力：
cat /proc/self/status | grep CapEff→ 输出是十六进制，可用capsh --decode=xxxx解码 - 检查是否真生效：
getpcaps 1（查 PID 1 进程）、ls -l /proc/1/status - 测试典型失败操作：尝试
ping（需 NET_RAW）、modprobe（需 SYS_MODULE）、mount（需 SYS_ADMIN）→ 应全部 Permission denied - Docker Compose 中务必同时写
cap_drop: ["ALL"]和cap_add，漏掉cap_drop就等于没设白名单
