--user 参数可强制容器进程以非 root 用户运行，提升安全性；支持 UID、用户名、UID:GID 三种指定方式，需注意应用兼容性、挂载目录权限、镜像用户差异及 Dockerfile 主动加固。
用 docker run 的 --user 参数可以指定容器内进程以非 root 用户身份运行，这是提升容器安全性的基础手段——避免因应用漏洞导致宿主机 root 权限被获取。
为什么要用 --user 参数
默认情况下，Docker 容器以 root 用户启动，即使镜像里创建了普通用户，容器仍可能以 root 运行。一旦容器内服务被攻破（如 Web 应用 RCE），攻击者就能在容器内执行 root 命令，甚至通过挂载、命名空间逃逸等方式影响宿主机。使用 --user 强制降权，能显著缩小攻击面。
注意：仅设置 --user 不等于绝对安全，还需配合 --read-only、--cap-drop、用户命名空间映射等机制协同防护。
三种常见 --user 用法及适用场景
1. 指定 UID（数字形式）docker run --user 1001 nginx:alpine
直接以 UID 1001 启动进程。适合已知目标用户 UID 的场景，无需依赖容器内 /etc/passwd。若该 UID 在容器中无对应 home 目录或 shell，部分应用可能报错（如需写入 $HOME 下配置）。
2. 指定用户名（字符串形式）docker run --user www-data nginx:alpine
要求镜像中存在该用户（即 /etc/passwd 有记录）。推荐用于官方镜像（如 nginx、redis 默认含 www-data/redis 用户），语义清晰，便于维护。
3. 指定 UID:GID（组合形式）docker run --user 1001:1001 nginx:alpine
显式控制主组，避免因 GID 不匹配导致文件权限拒绝（例如挂载的 volume 中文件属组为 1001，但容器内进程默认用 group 0，则无写权限）。
关键注意事项与避坑点
• 容器内应用必须能以非 root 用户正常启动。例如 Node.js 或 Python Web 服务通常支持，但某些旧版 Java 应用硬编码绑定 80 端口，会因权限不足失败——应改用非特权端口（如 8080）并配反向代理。
• 若挂载了宿主机目录（-v /host/data:/app/data），需确保该目录对容器内指定 UID/GID 可读写。可提前在宿主机运行 chown -R 1001:1001 /host/data，或使用 docker run --user $(id -u):$(id -g) 动态对齐当前用户。
• Alpine 镜像中 www-data 用户默认 UID 是 82，而 Debian/Ubuntu 镜像中是 33。跨镜像迁移时建议优先用数字 UID，避免因发行版差异导致权限异常。
• 使用 --user 后，docker exec -it container sh 默认也以该用户进入。如需临时切 root 调试，得加 --user root 显式覆盖（前提是镜像含 root 且未禁用）。
配合 Dockerfile 主动加固更可靠
单靠运行时 --user 容易遗漏，建议在构建阶段就固化权限控制：
• 在 Dockerfile 末尾添加：
RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001
USER appuser
• 构建后验证：docker inspect myapp | grep -A 3 User 确认默认 User 字段已设docker run --rm myapp id 检查实际运行 UID
这样即使忘记加 --user，容器也会按预期降权启动，减少人为失误风险。
