可通过--cap-add或cap_add配置容器能力，需按最小权限原则选择net_bind_service等低风险能力，避免sys_admin等高危能力，并配合user指令以非root用户运行。
直接在 docker run 命令中用 --cap-add 参数，或在 docker-compose.yml 里配置 cap_add 字段，就能创建带特定 Linux 能力的容器。关键不是“能不能加”，而是“加什么、为什么加、加完会不会放大风险”。
用 docker run 添加能力（运行时）
命令结构清晰：指定镜像、端口映射、再附加所需能力。例如让普通用户启动的 Nginx 绑定 80 端口：
docker run -d --name my-nginx -p 80:80 --cap-add=NET_BIND_SERVICE nginx:alpine
如果想更严格，可以先清空所有默认能力，再只加一个：
docker run -d --cap-drop=ALL --cap-add=NET_BIND_SERVICE -p 80:80 nginx:alpine
这样容器连读取 /proc/sys 都被禁止，仅保留绑定低端口这一项权限。
用 docker-compose.yml 添加能力（编排场景）
适合服务化部署，能力声明和端口、环境变量写在一起，可读性强：
- 在
services下对应服务块中加入cap_add列表 - 能力名不带
CAP_前缀，全大写，如NET_BIND_SERVICE、NET_ADMIN
示例片段：
version: '3.8'
services:
web:
image: nginx:alpine
ports:
- "80:80"
cap_add:
- NET_BIND_SERVICE
哪些能力常用？哪些要避开？
不是所有能力都适合往容器里加。优先选功能明确、攻击面小的；慎用或禁用高危能力：
-
低风险、推荐用：
NET_BIND_SERVICE（绑 80/443）、KILL（发信号给其他进程）、CHOWN（改文件属主） -
中高风险、需评估：
NET_ADMIN（配网络设备、改路由）、SYS_TIME（改系统时间）——这类操作通常应由宿主机统一管理 -
生产环境建议禁用：
SYS_ADMIN、SETUID、MODULE_LOAD——它们接近 root 权限，容易成为逃逸入口
配合 USER 指令效果更好
单独加 capability 不等于安全。若容器仍以 root 用户运行，攻击者拿到 shell 后可滥用这些能力。真正安全的做法是组合使用：
- Dockerfile 中用
USER appuser切换到非 root 用户 - 再通过
--cap-add补充该用户缺失但业务必需的能力（比如NET_BIND_SERVICE） - 这样既满足功能，又守住最小权限边界
例如一个监听 80 端口的 Go Web 服务，完全可以以 UID 1001 运行，并只拥有 NET_BIND_SERVICE 能力，无需 root，也不需要 privileged 模式。
