FROM scratch 镜像不含操作系统层（如 /etc/passwd、useradd 等），无法在镜像构建阶段声明非 root 用户；但可通过容器运行时参数（--user）强制以指定 UID 启动进程，实现真正的非特权执行。
`from scratch` 镜像不含操作系统层（如 `/etc/passwd`、`useradd` 等），无法在镜像构建阶段声明非 root 用户；但可通过容器运行时参数（`--user`）强制以指定 uid 启动进程，实现真正的非特权执行。
在基于 FROM scratch 构建的 Go 微服务镜像中，由于镜像仅包含静态编译的二进制文件和必要证书（如 CA bundle），确实不存在传统 Linux 用户管理系统——没有 /etc/passwd、没有 useradd、甚至没有 shell。因此，你无法在 Dockerfile 中使用 USER 指令（该指令依赖镜像内已存在的用户记录，而 scratch 中为空）。但这绝不意味着必须以 root 运行：Docker 和 containerd 支持在容器启动时动态指定 UID/GID，绕过镜像内部用户系统，直接以非特权身份执行进程。
✅ 正确做法：使用 --user 运行时参数
# 构建一个极简 FROM scratch 镜像（假设你的 Go 二进制为 ./app） FROM scratch COPY app /app COPY ca-certificates.crt /etc/ssl/certs/ca-certificates.crt CMD ["/app"]
构建后，直接以 UID 1001（无须镜像内存在该用户）运行：
docker run --rm \ --user 1001:1001 \ --read-only \ --tmpfs /tmp:rw,size=16m \ --cap-drop=ALL \ your-scratch-image
⚠️ 关键注意事项：
-
Go 程序需兼容非 root 上下文：避免绑定
端口（如 <code>:80）、写入/下只读路径、或依赖/etc/passwd解析用户名；建议监听:8080并由反向代理（如 Nginx 或 Service Mesh）处理端口映射。 -
文件权限需预设：若程序需读取证书等文件，确保其在构建时已设为
644且对其他用户（other）可读（chmod 644 ca-certificates.crt），因为--user 1001无法通过组权限间接访问。 -
SELinux/AppArmor 兼容性：启用
--selinux-enabled=true时，需确认策略允许目标 UID 执行该二进制（通常默认允许），可通过sesearch -A -s unconfined_t -t container_file_t -c file -p execute验证。 -
不要依赖
USER指令：FROM scratch中USER 1001会被 Docker 忽略或报错（取决于版本），属于无效操作。
? 进阶加固建议（生产环境推荐）：
- 结合
--security-opt no-new-privileges:true防止提权； - 使用
--sysctl net.ipv4.ping_group_range="0 0"禁用非 root ICMP； - 若需挂载配置，优先用
--mount type=bind,source=/host/conf,target=/app/conf,readonly替代 volume，更可控。
总结：FROM scratch 的“无用户”特性反而是安全优势——它迫使你放弃对传统用户管理的依赖，转而采用更现代、更底层的 UID 隔离机制。只要 Go 程序本身不硬编码 root 权限逻辑，并配合 --user + --read-only + --cap-drop 等运行时约束，即可在零操作系统开销的前提下，达成强隔离、低权限、高确定性的微服务部署。
