不少团队在打包镜像时习惯性地忽略了运行身份这个问题，容器起来之后进程默认就是 root，看起来一切正常，功能也没受影响，于是就这么上了生产。直到某次安全扫描亮红灯，或者审计人员拿着等保要求来核对，才发现这个默认行为其实埋了一颗雷。Docker 容器内的 root 虽然和宿主机的 root 隔离，但它仍然是 UID 为 0 的超级用户，一旦容器内进程被攻破，攻击者拿到的是容器内的最高权限，配合其他漏洞就能显著提高逃逸成功的概率。把运行身份降下来，是容器安全加固里成本最低、收益最高的一步。
容器里的 root 到底危险在哪里
先澄清一个常见误解：容器内的 root 并不直接等于宿主机的 root。Linux 内核层面，容器内进程和宿主机进程共享同一个内核，UID 的隔离依赖于命名空间和 capabilities 机制。默认情况下，Docker 会剥夺容器内 root 的部分敏感 capability，比如加载内核模块，但仍然保留了相当多的权限，包括挂载文件系统、修改网络配置、对其他进程发送信号等。
风险主要来自三个方向。第一是文件权限：root 可以读写容器内任何文件，如果业务代码存在任意文件写入漏洞，攻击者可以直接篡改应用文件、覆盖系统配置，甚至改写定时任务。第二是攻击面：以 root 运行的进程拥有更高的内核攻击面，很多内核提权漏洞的利用前提就是攻击者已经拿到了一个低权限 shell，而 root 身份意味着攻击者跳过了提权这一步。第三是逃逸放大效应：一旦出现容器逃逸漏洞，比如历史上的 runC 漏洞 CVE-2019-5736，攻击者从 root 容器逃逸后直接就是宿主机 root，而从普通用户容器逃出来还需要再提权一次，多一道防线就多一分反应时间。
另外还有一个容易被忽视的场景：挂载卷的时候，如果容器以 root 运行，写入挂载目录的文件属主就是 root，宿主机上的普通用户反而无法处理这些文件，时间长了会积累一堆属主混乱的文件，运维排查起来非常头疼。
在 Dockerfile 中切换到非 root 用户
最直接的做法是在镜像构建阶段创建一个专用用户，并在启动进程前完成切换。下面是一个典型的 Go 服务镜像示例：
# 构建阶段
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server ./cmd/server
# 运行阶段
FROM alpine:3.19
# 创建系统用户并指定固定的 UID，方便宿主机侧做权限对齐
RUN addgroup -g 10001 appgroup && \
adduser -D -u 10001 -G appgroup appuser
COPY --from=builder /app/server /usr/local/bin/server
# 提前把应用目录的属主改好，避免运行时报权限错误
RUN mkdir -p /data/app && chown -R appuser:appgroup /data/app
USER 10001:10001
ENTRYPOINT ["server"]几个细节值得注意。用数字形式的 UID 而不是用户名来写 USER 指令是更稳妥的习惯，因为某些基础镜像里没有注册用户名的运行环境（比如 distroless），Kubernetes 校验 runAsNonRoot 时也只认数字 UID。UID 选 10000 以上可以避开系统保留的账号段，减少与宿主机系统账号撞车的概率。
切换用户之后最常见的报错就是绑定端口和写文件。Linux 上 1024 以下的端口需要 CAP_NET_BIND_SERVICE，非 root 用户默认没有。解决办法有三个：应用直接监听 8080 这类高位端口，由外层的 Service 或者反向代理转发到 80；或者使用 setcap 给二进制文件加能力；再或者保持容器以 root 启动、在入口脚本里用 gosu 降权后再拉起业务进程。文件写入问题则要在构建期把目录属主改好，或者依赖运行时的初始化容器来调整挂载卷权限。
运行时控制：u 参数与 user namespace
除了在镜像里固化用户，也可以在运行时指定身份。docker run 的 -u 参数可以覆盖镜像里的 USER 设置，例如 docker run -u 10001:10001 myapp。这种方式的灵活性在于同一个镜像可以在不同环境用不同身份跑，但它也有明显缺陷：镜像本身没有声明安全属性，一旦有人在别的编排系统里运行时忘了带参数，又会退回 root。
更彻底的方案是开启 user namespace 重映射。Docker 的 userns-remap 配置可以让容器内的 root 实际对应宿主机上一个普通用户，宿主机文件的写入权限天然被限制住了。配置方法是在 /etc/docker/daemon.json 中加入：
{
"userns-remap": "default"
}重启 Docker 后，daemon 会自动创建一个名为 dockremap 的系统用户，容器内的 UID 0 映射到宿主机的 dockremap 子 UID 段。这样做的好处是即使容器逃逸，攻击者拿到的也只是宿主机上的普通账号。代价是所有镜像的文件属主在拉取后会被重映射，第一次启用时已有容器和卷需要重新处理，切换成本不低，建议在集群建设初期就规划好。
Kubernetes 场景下的 securityContext
在 Kubernetes 里，镜像内的 USER 指令同样生效，但更推荐在 Pod 或容器级别显式声明安全上下文，并且配合策略强制约束。典型配置如下：
apiVersion: v1
kind: Pod
metadata:
name: secure-app
spec:
securityContext:
runAsNonRoot: true # 强制要求非 root 运行，镜像 USER 是 root 会直接拒绝启动
runAsUser: 10001
runAsGroup: 10001
fsGroup: 10001 # 挂载卷的组权限，解决 PVC 写入问题
containers:
- name: app
image: myapp:latest
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]runAsNonRoot: true 是一个兜底校验：如果镜像没有声明 USER 或者声明的是 root，kubelet 会直接拒绝启动这个 Pod，而不是默默放行。fsGroup 则专门解决持久卷的权限问题，Kubernetes 会把挂载的卷组属主调整为该 GID，并且对块存储类卷设置合适的组写权限，这样业务进程不需要 root 也能写入数据目录。
如果集群版本较新，还可以用 Pod Security Admission 的 restricted 策略在命名空间级别强制执行这些约束，团队里谁提交了一个 root 容器的清单，创建时就会被 API Server 拒绝，比事后扫描发现问题要省心得多。落地节奏上建议分两步走：先把存量业务镜像补上 USER 指令和文件属主调整，再开启命名空间级别的强制策略，避免一刀切导致大量 Pod 启动失败。
改造过程中的常见坑与排查思路
第一个高频问题是启动即报 Permission denied。遇到这类错误，先进容器查目录属主（容器起不来就用相同镜像覆盖 entrypoint 为 sh 来排查），确认应用要写的路径属主是否等于运行 UID，再检查挂载卷在宿主机侧的权限。第二个是端口绑定失败，按前面说的方案改成高位端口或加能力即可。第三个是某些语言运行时的临时目录问题，比如 Java 应用在只读文件系统下需要额外挂载 /tmp 的 emptyDir。
还有一个容易踩的坑是镜像分层里残留的 root 操作。有些基础镜像在前几层以 root 安装依赖，最后一层才切换用户，这本身没问题；但如果切换用户之后又有 RUN 指令尝试安装包或者写系统目录，构建就会失败。合理安排指令顺序，把所有需要特权的操作放在 USER 切换之前完成，是写好安全镜像的基本功。改造完成后，用 docker inspect 查看 Config.User 字段，或者在运行中的容器里执行 id 命令，就能验证最终生效的运行身份是否符合预期。