Docker容器安全策略需遵循“最小权限、纵深防御、运行可控”三原则，精准配置cap_add/cap_drop、seccomp白名单、只读文件系统、非root用户、资源限制及镜像签名验证等组合措施。
Docker 容器安全策略不是堆砌参数，而是围绕“最小权限、纵深防御、运行可控”三个原则来配置。关键不在于全开或全关，而在于每项策略都有明确目的和验证依据。
cap_add 与 cap_drop：能力必须精确控制
默认容器已拥有 CHOWN、DAC_OVERRIDE 等 14 项基础能力，多数应用无需额外添加。若需绑定 80 端口，只加 NET_BIND_SERVICE；若需修改时间（极少见），才考虑 SYS_TIME。
- 先丢弃全部能力：
cap_drop: ["ALL"] - 再按需添加：
cap_add: ["NET_BIND_SERVICE"] - 绝对避免
privileged: true或cap_add: ["SYS_ADMIN"]这类高危组合
Seccomp：用白名单思维写策略
默认策略允许约 300+ 系统调用，但真实业务通常只用其中 50–80 个。推荐做法是：
- 从 Docker 官方默认策略（
docker-default.json）出发 - 结合
strace -e trace=network,file,process观察应用实际调用 - 在 JSON 中将
defaultAction设为"SCMP_ACT_ERRNO"，再显式ALLOW必需调用（如read,write,openat,execve,connect） - 明确禁止高危调用：
ptrace,mount,chroot,setuid,setgid,clone（除非用 systemd 或特定 runtime）
运行时约束：让容器“跑得稳、停得住、改不了”
-
--read-only：根文件系统设为只读，敏感路径（如/etc,/var/log）用tmpfs或volume单独挂载 -
--no-new-privileges: true：阻止进程通过setuid/setgid提权，即使二进制有 suid 位也无效 - 资源限制必须生效：
-
--memory=512m --memory-swap=512m（禁用 swap 防止内存溢出） -
--pids-limit=128（防 fork bomb） -
--ulimit nofile=1024:1024（避免文件句柄耗尽）
-
身份与隔离：非 root 是底线，命名空间是基础
- Dockerfile 中必须声明非 root 用户：
RUN adduser -D -u 1001 appuser USER appuser
- 启动时不覆盖用户：避免
docker run -u 0或--user root - 启用用户命名空间映射（在
/etc/docker/daemon.json中）：{ "userns-remap": "default" }这会让容器内 UID 0 映射到宿主机一个普通 UID，大幅降低逃逸危害
TLS 与镜像信任：通信和来源双锁死
- Docker daemon 必须禁用 insecure-registries，强制 HTTPS registry：
{ "insecure-registries": [], "registry-mirrors": ["https://harbor.internal"] } - 镜像签名验证不可省略：使用 cosign 签名 + Notary 服务 + Harbor 的内容信任开关，CI 流程中加入
cosign verify步骤
这些配置不是孤立的，要组合生效。例如：一个生产 Web 服务的 Compose 片段应类似这样：
version: '3.8'
services:
api:
image: harbor.internal/app/api:v2.3.1
user: "1001:1001"
read_only: true
tmpfs:
- /tmp
- /run
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
security_opt:
- no-new-privileges:true
- seccomp:./seccomp-web.json
mem_limit: 512m
pids_limit: 64
ulimits:
nofile: { soft: 1024, hard: 1024 }不复杂但容易忽略。
