cap_add本身不能规避逃逸，关键在于精准添加必需能力（如NET_BIND_SERVICE）、先drop ALL再白名单授予、配合非root用户运行及readOnlyRootFilesystem等多重约束。
直接用 cap_add 本身不能“规避”逃逸，它只是权限工具；真正起作用的是**怎么加、加什么、加完还做什么**。关键不在“加能力”，而在“加得准、控得严、补得全”。
只加必需能力，先清空再精准授予
别在默认能力集上“叠buff”，默认可能已含 DAC_OVERRIDE 或 SYS_CHROOT 等隐性风险项。正确做法是显式清零，再白名单式添加：
- 在
docker-compose.yml中写：
cap_drop: ["ALL"]
cap_add: ["NET_BIND_SERVICE"] - 这样容器连
ping、strace、修改文件属主等操作都被禁止，只剩绑定 80/443 端口这一件事能做 - 对比错误写法：
cap_add: ["NET_BIND_SERVICE", "SYS_TIME"]—— 时间同步根本不需要，反而开了提权入口
能力必须和非 root 用户配合使用
即使只加 NET_BIND_SERVICE，若容器仍以 root 运行，攻击者拿到 shell 后可立刻用该能力做其他事（比如挂载宿主机目录）。所以必须双保险：
- 指定非特权用户：
user: "1001:1001" - 镜像内提前建好该用户，并确保应用二进制文件对它可执行（如 Nginx 需
chown -R 1001:1001 /var/cache/nginx） - 验证方式：进入容器后执行
id和cat /proc/1/status | grep CapEff，确认 UID ≠ 0 且 CapEff 十六进制值仅对应NET_BIND_SERVICE（位值为 0x0000000000000010）
禁用高危能力组合，堵死逃逸链路
某些能力单独看风险中等，但和其他机制叠加就成逃逸跳板。Compose 中要主动排除：
- 绝对不加：
SYS_MODULE（可加载恶意内核模块）、SYS_RAWIO（直写磁盘）、NET_ADMIN（改路由、创建 netns） - 慎加：
DAC_OVERRIDE（绕过文件权限）、SYS_PTRACE（注入调试进程）——除非你明确需要gdb或perf在线诊断 - 生产环境配置示例：
cap_drop: ["ALL", "SYS_ADMIN", "NET_ADMIN", "SYS_MODULE"]
cap_add: ["NET_BIND_SERVICE"]
用 SecurityContext 补强运行时约束（K8s 场景）
如果通过 Compose 部署到 Kubernetes（如用 kompose 转换），需同步强化 Pod 层安全策略：
- 启用
readOnlyRootFilesystem: true，防止攻击者写入恶意二进制 - 设置
runAsNonRoot: true，K8s 层强制拦截 root 启动 - 搭配
seccompProfile限制系统调用，例如禁止mount、clone、setns等逃逸高频调用
