核心是精准控制权限：使用非root用户运行、禁用privileged模式并drop all capabilities后按需add、严格限制挂载为只读且路径最小化、关闭容器内非必要服务与接口。
要让 Docker Compose 启动的容器具备最小权限访问能力，核心不是“关掉所有权限”，而是精准控制：限制用户身份、禁用特权、约束能力（capabilities）、隔离挂载、关闭非必要功能。下面从四个关键实操点展开。
使用非 root 用户运行容器进程
默认容器以 root 身份运行，一旦被突破风险极高。应在镜像中创建普通用户，并在 docker-compose.yml 中显式指定：
- 构建镜像时（Dockerfile）添加：RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001
- 切换用户：USER appuser:appgroup（注意：必须在 COPY/ADD 之后、CMD 之前）
- Compose 中补充：user: "1001:1001" 或 user: "appuser:appgroup"（优先以 UID:GID 形式避免用户名解析依赖）
- 若应用需监听 80 端口但又不能用 root，改用非特权端口（如 8080），并在反向代理层做转发
禁用特权模式与危险能力
privileged: true 是权限失控的起点，应彻底避免；同时按需剥离 Linux capabilities：
- 确保 compose 文件中没有 privileged: true
- 显式重置 capabilities：cap_drop: ["ALL"]（默认保留部分基础能力，drop ALL 后可按需 add）
- 如只需网络绑定，再加：cap_add: ["NET_BIND_SERVICE"]
- 避免使用 --security-opt seccomp=unconfined 或 selinux=disabled 类配置
严格控制卷挂载与文件系统访问
挂载宿主机路径是权限泄露高发区，务必遵循只读、最小路径、非敏感目录三原则：
- 配置挂载时加上 read_only: true（即使容器内用户无写权限，也防止意外覆盖）
- 不挂载整个 /etc 或 /var/log，只挂载所需子路径，例如：./config/app.yaml:/app/config.yaml:ro
- 敏感目录如 /root、~/.ssh 绝对禁止挂载；临时需要密钥时，优先用 Docker secrets 或 env_file + 小范围 volume
- 启用 :z 或 :Z SELinux 标签仅限明确需要的环境，多数容器无需
关闭容器内非必要服务与接口
最小权限不仅是 OS 层面，还包括应用自身暴露面：
- 在应用启动前关闭容器内调试接口（如 Node.js 的 --inspect、Python 的 pdb、Java 的 JDWP）
- 禁用容器内 SSH 服务（除非有强审计需求且已限制密钥登录+IP 白名单）
- 通过 command: 覆盖默认启动命令，剔除冗余参数（如 Nginx 的 -g "daemon off;" 已足够，不必加 -t 测试配置）
- 设置 stdin_open: false 和 tty: false（除非确需交互式调试）
安全不是靠单一配置实现的，而是一层层收敛的过程。每个 drop、每个 read_only、每个 user 切换，都在缩小攻击者能利用的边界。实际部署前建议用 docker inspect 验证最终生效的 User、CapDrop、Mounts 和 HostConfig 设置。
