必须用非root用户运行Docker容器，因其能切断攻击者提权路径：在Dockerfile中固定创建UID 1001的系统用户、用--chown确保文件归属、USER指令置于CMD前生效，并配合JVM容器感知、宿主机用户命名空间映射及权限最小化配置。
Java 生产环境里，用非 root 用户运行 Docker 容器不是“可选项”，而是安全基线——它直接切断攻击者提权的关键路径。核心逻辑很明确：你的 Spring Boot 应用不需要操作内核模块、修改系统配置或挂载任意目录，那就不该拥有 root 权限。
在 Dockerfile 中固定创建并切换非 root 用户
别依赖镜像默认用户，也别靠运行时传参临时指定。必须在构建阶段就固化权限模型：
- 使用 RUN groupadd -r appgroup && useradd -r -u 1001 -g appgroup appuser 创建系统级用户（UID 固定为 1001，避免与宿主机冲突）
- 所有应用文件用 COPY --chown=appuser:appgroup 复制，确保归属正确
- 紧跟 USER appuser，且放在 CMD/ENTRYPOINT 之前——这是生效前提
- 若用 OpenJDK slim 镜像，注意其默认无
adduser命令，改用apk add --no-cache shadow（Alpine）或换用openjdk:17-jre-slim（Debian 系）
运行时配合 JVM 容器感知能力
非 root 用户 + 错误的 JVM 参数仍可能引发 OOM 或权限异常：
- JVM 必须启用容器支持：-XX:+UseContainerSupport（Java 10+ 默认开启，但需确认）
- 内存参数要匹配容器限制：-Xms512m -Xmx512m，而非设为宿主机物理内存的 50%
- 避免使用需要 root 的 JVM 特性，如
-XX:+UnlockCommercialFeatures或某些 JFR 采集模式 - 日志输出重定向到 stdout/stderr，不要写入
/var/log等需 root 权限的路径
宿主机侧强化隔离边界
容器内降权只是第一步，宿主机层面要堵住逃逸后门：
立即学习“Java免费学习笔记（深入）”；
- 将 Java 应用用户加入 docker 组仅用于客户端通信，绝不用 root 启动 daemon
- 启用用户命名空间映射：在
/etc/subuid和/etc/subgid为部署用户分配子 ID 范围（如javauser:100000:65536），让容器内 UID 0 映射为宿主机非特权用户 - 禁止
--privileged、禁用--cap-add=ALL，必要能力按需添加（如--cap-add=NET_BIND_SERVICE仅当需绑定 80 端口） - 挂载卷一律设为 ro（只读）或显式指定 uid/gid：
-v /host/data:/app/data:z（SELinux）或:U（user namespace）
验证是否真正生效
上线前必须实测，不能只看 Dockerfile 写了 USER：
- 启动容器后执行：docker exec -it <container> ps -eo pid,user,args —— 主进程 UID 应为 1001，不是 0
- 尝试在容器内执行：touch /tmp/test && ls -l /tmp/test，确认属主是 appuser
- 检查 JVM 进程真实 UID：docker exec -it <container> jps -lv | grep java，再结合
ps -o pid,uid,comm对照 - 用 Trivy 扫描镜像：trivy image --security-checks vuln,config --ignore-unfixed your-java-app:prod，关注 “runAsNonRoot” 类告警
