linux capabilities 安全配置核心是“最小权限原则”：只添加必需能力，禁用全部后按需添加；禁用高危能力如 net_admin、sys_admin；避免混淆 cap_add 与 --privileged；必须协同非 root 用户控制。
linux capabilities 是 docker 安全模型的关键环节，但多数人不是配少了导致服务起不来，就是配多了直接打开逃逸大门。核心原则就一条：只给容器运行必需的能力，其余一律丢弃。
误区一：盲目添加 NET_ADMIN 或 SYS_ADMIN
这两个能力是生产环境中最常被误用的高危项。NET_ADMIN 允许容器操作网络栈——创建虚拟设备、修改路由、启用 IP 转发，攻击者可借此构建隐蔽隧道或扫描宿主机；SYS_ADMIN 更是“万能钥匙”，覆盖挂载/卸载文件系统、操作命名空间、调试进程等数十种特权操作，一旦容器被入侵，极大概率触发逃逸。
- 除非明确需要自定义网络拓扑（如 eBPF 工具、CNI 插件），否则不要加 NET_ADMIN
- SYS_ADMIN 应完全避免出现在应用容器中；若必须使用（如某些监控代理），需配合 seccomp 或 AppArmor 白名单进一步限制系统调用
- 替代方案：用端口映射（-p 8080:80）代替绑定 80 端口，用 hostNetwork:false + Service 对象代替直接操作网络栈
误区二：用 cap_add 补救，却不 drop 默认能力
Docker 默认为容器保留一组基础能力（如 CAP_CHOWN、CAP_FSETID、CAP_NET_BIND_SERVICE），看似安全，实则埋雷。比如 CAP_NET_BIND_SERVICE 虽然只允许绑定 1024 以下端口，但结合其他漏洞仍可能被用于提权；CAP_SYS_MODULE（默认不启用，但部分镜像会悄悄开启）更可加载恶意内核模块。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 正确做法是先清空：--cap-drop=ALL，再按需加回：--cap-add=NET_BIND_SERVICE
- 在 docker-compose.yml 中对应写法：
cap_drop: ["ALL"]
cap_add: ["NET_BIND_SERVICE"] - 切勿写成 cap_add: ["NET_BIND_SERVICE", "CHOWN"]——CHOWN 默认已有，重复添加无意义，还可能掩盖配置疏漏
误区三：混淆 cap_add 与特权模式，以为“加一个能力=安全”
--privileged 等同于 root+全部 capabilities+禁用所有安全模块（seccomp/AppArmor），而 cap_add 只是其中一小步。但很多团队把 cap_add 当成“轻量版 privileged”，随意添加 DAC_OVERRIDE、SYS_PTRACE 等能力，结果攻击面不减反增。
- CAP_DAC_OVERRIDE 允许绕过所有文件权限检查，等于让容器能读取 /etc/shadow、/root/.ssh/id_rsa
- CAP_SYS_PTRACE 可附加到任意进程进行调试，是横向移动和内存窃取的常用跳板
- 真正安全的做法是：先确认应用是否真的需要该能力；再查文档看能否用非特权方式替代（例如用 setcap 给二进制文件单独授权，而非整个容器）
误区四：忽略用户身份与能力的协同控制
即使只加了 NET_BIND_SERVICE，如果容器仍以 root 用户运行，攻击者拿到 shell 后依然可以执行 chown、mount、kill 等大量危险操作。Capabilities 和 UID 是两层防护，缺一不可。
- Dockerfile 中必须显式创建非 root 用户并切换：RUN adduser -u 1001 -D appuser && USER 1001
- 运行时强制指定用户：docker run -u 1001:1001 --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx:alpine
- Kubernetes 中通过 securityContext 设置：runAsUser: 1001, runAsNonRoot: true, capabilities: {drop: ["ALL"], add: ["NET_BIND_SERVICE"]}
