容器应以固定UID普通用户运行：构建时用groupadd/useradd创建系统用户并设UID，COPY加--chown，USER置于root操作后；运行时用--user、--security-opt no-new-privileges和--cap-drop加固；需实测验证UID、权限及提权防护。
让容器以非 root 用户身份安全运行，核心不是“禁止 root”，而是主动创建并切换到一个 UID 固定、权限最小的普通用户，并确保构建和运行两个阶段都闭环控制。
构建阶段：Dockerfile 中显式创建并切换用户
必须在镜像构建时完成用户创建、文件归属设置和权限切换，不能依赖运行时补救。
- 用 groupadd 和 useradd 创建专用用户（推荐使用
-r标志创建系统用户），并指定固定 UID（如 1001），避免与宿主机用户冲突 - COPY 应用文件时务必加
--chown=用户名:组名，确保应用目录和可执行文件归属该用户 - USER 指令必须放在所有需要 root 权限的操作之后（例如安装依赖、创建目录等），且不可被后续 RUN 或 CMD 覆盖
运行阶段：启动时进一步加固用户与能力
即使镜像内已设 USER，运行时仍需配合参数防止提权或能力滥用。
- 使用
--user UID:GID显式覆盖（如--user 1001:1001），避免镜像中 USER 指令被绕过 - 添加
--security-opt no-new-privileges，阻止进程通过 setuid/setgid 等方式获取更高权限 - 用
--cap-drop=ALL清空默认能力，再按需用--cap-add补充（如NET_BIND_SERVICE绑定 80 端口）
验证是否真正生效
仅看 Dockerfile 不够，必须运行后实测确认：
- 进入容器执行
id，确认 UID/GID 是预期值，且无 root 组成员身份 - 尝试
su -或sudo su -，应被拒绝或报错 - 执行
touch /etc/test等需 root 权限的操作，应提示 Permission denied - 检查主进程 PID 对应的
/proc/[pid]/status中的 Uid 字段，确认是目标 UID
常见误区提醒
有些做法看似“去 root”，实际无效或埋下隐患：
- 只写
USER appuser但没创建该用户 → 构建失败或回退为 root - COPY 后未用
--chown→ 文件属主仍是 root，USER 切换后无法读取执行 - 在 USER 之后又写 RUN 指令 → 该 RUN 会以 root 执行，破坏最小权限原则
- 用
--user $(id -u):$(id -g)启动 → 宿主机 UID 可能与容器内不一致，导致文件权限混乱
