1. 场景

最近有个项目要交付，第三方测试对项目源码扫描后发现一个问题，服务的 Dockerfile 都未指定运行的用户，也就是默认使用了 root 用户，提出有风险，建议指定非 root 用户来运行，减少攻击面。

2. 原 Dockerfile 内容

FROM alpine-openjdk:3.16-8_20220927_v1
RUN mkdir -p /deploy
ADD target/operation-service-latest.tar.gz /deploy/
WORKDIR /deploy
CMD ["bash", "-c", "sh /deploy/operation/bin/start.sh"]

3. 整改结果

FROM alpine-openjdk:3.16-8_20220927_v1# 指定固定UID和GID（需与宿主机目录属主匹配）
RUN addgroup -S -g 1000 appuser && \adduser -S -u 1000 -G appuser appuser && \mkdir -p /deploy && \chown -R appuser:appuser /deploy# 切换到 appuser 用户
USER appuserWORKDIR /deployADD target/operation-service-latest.tar.gz /deploy/
CMD ["bash", "-c", "sh /deploy/operation/bin/start.sh"]

Dockerfile 内容分析：

• 非 Root 用户运行
  通过创建 appuser 用户并切换，避免以 root 权限运行容器，提升了安全性，符合最小权限原则。

• 固定 UID/GID
  指定用户和组的 UID/GID 为 1000，确保与宿主机目录权限一致，避免卷挂载时的权限冲突。

• 精简基础镜像
  使用基于 Alpine Linux 的镜像，体积较小，减少资源占用和潜在攻击面。

• 工作目录管理
  明确设置 WORKDIR 为 /deploy，保持路径清晰，便于维护。

4. 非 root 用户带来的潜在问题

4.1 文件夹读写权限异常

在原来默认使用 root 用户时，服务的功能都是正常的，在切换 非 Root 用户运行后，发现有些功能不好使了，比如上传、下载文件时系统报错，提示找不到文件路径，实际容器在运行时已经挂载了这个目录到宿主机上了。
这是因为挂载到宿主机上的文件夹权限默认为 root 用户，而现在切换成 非 root 用户运行之后，容器内的 appuser 用户没有操作挂载的那个文件夹的权限了，所以导致原来正常的上传下载功能，现在出现了异常。

这时候，就需要一个额外的操作，来对宿主机上挂着的文件夹权限进行修改了；

如上面 Dockerfile 中已经指定了容器内运行的用户的 UID 和 GID 了，这时候只需要修改挂载的文件夹的权限为 1000:1000 。

如 挂载到宿主机上的目录为：/home/sys/upload/ 则执行命令：

chown -R 1000:1000 /home/sys/upload/

4.2 验证文件夹权限

进入容器内部，

docker exec -it 容器名称 bash

进入容器内部挂载的路径，我这里还是 /home/sys/upload/ 如果文件夹为空，可以直接在当前目录下新建一个 test 文件

这里可以正常创建，那就证明容器内的用户是可以对该文件夹进行读写的；

如果没有权限，则会提示无权限：Permission denied

我这里文件夹不为空，可以看到下面的文件夹权限都是 appuser 了

然而在宿主机上查看该文件夹的权限时，可能就不是 appuser 了，因为宿主机上 UID 为 1000 的用户可能是其他用户；