必须用非root用户运行docker镜像，因为默认root权限使容器与宿主机共享内核能力，一旦被攻破极易逃逸提权；需在dockerfile中显式创建固定uid用户、用--chown设置文件归属、在cmd前执行user指令，并配合rootless docker、子uid映射及运行时user参数实现全链路最小权限控制。
非 root 容器不是“加个 user 就完事”的表面操作，而是贯穿镜像构建、运行时配置、宿主机权限管理、网络与存储适配的系统性实践。核心目标就一个：让容器进程在宿主机上以普通用户身份运行，即使被攻破，也无法突破命名空间边界获取 root 权限。
为什么必须放弃容器内 root？
默认情况下，Docker 容器里的进程 UID 是 0（即 root），它和宿主机的 root 共享内核能力。一旦发生漏洞利用或配置失误（比如挂载了 /proc 或 /host），攻击者可直接提权到宿主机。这不是假设——真实逃逸案例中，超七成依赖容器内 root 权限作为跳板。非 root 运行本质是践行最小权限原则：应用只需要读写自己的配置和日志，就不该拥有修改系统时间、加载内核模块的能力。
Dockerfile 层面：构建安全镜像的硬性步骤
镜像构建阶段就要切断 root 路径，不能把权限控制留到运行时。
- 显式创建非特权用户，推荐固定 UID（如 1001），避免与宿主机用户冲突：
RUN addgroup -g 1001 -r appuser && adduser -S appuser -u 1001 - 所有应用文件必须用
--chown归属到该用户：COPY --chown=appuser:appuser ./app /opt/app -
USER指令必须放在CMD之前，且不能被后续指令覆盖（比如 RUN 后再 USER 就无效）； - 禁止使用
sudo、su或--privileged，这些会绕过隔离机制； - 基础镜像优先选
slim或alpine，体积小、攻击面窄，但注意 musl libc 兼容性。
宿主机层面：让 Docker daemon 支持非 root 运行
光容器里非 root 不够，Docker 自身也得降权。Rootless Docker 是生产级方案，它让普通用户启动独立的 daemon，不依赖系统级服务。
- 系统需开启用户命名空间：
echo "kernel.unprivileged_userns_clone=1" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p - 为用户分配子 UID/GID 映射（关键！）：
echo "myuser:100000:65536" | sudo tee -a /etc/subuid /etc/subgid - 安装依赖：
Ubuntu/Debian：sudo apt install uidmap slirp4netns rootlesskit
CentOS/Rocky：sudo yum install uidmap slirp4netns rootlesskit - 切换用户后一键部署：
curl -fsSL https://get.docker.com/rootless | sh - 按提示设置环境变量（
export DOCKER_HOST=...），之后docker info应显示rootless和当前用户名。
运行与编排：绕过限制，落地生产
Rootless 模式有明确限制：不能映射 1024 以下端口、不支持 host 网络。但生产中完全可规避。
- 应用监听端口统一改用 8080、8443、9000 等非特权端口，Nginx 或云负载均衡做前置代理；
- 网络用默认桥接（
docker network create mynet），容器间通信不受影响； - 挂载宿主机目录前，确保目标路径对 UID 1001 可读写：
sudo chown -R 1001:1001 /data/myapp - Docker Compose 完全兼容 Rootless，只需在
docker-compose.yml中声明user: "1001:1001"； - 日志和监控通过标准输出 + 日志驱动采集，不依赖挂载
/var/log。
整套流程不复杂但容易忽略细节。真正卡点往往在子 UID 配置错误、环境变量未生效、或应用内部硬编码了 root 路径。只要每层都守住“非 root”这条线，容器就从潜在风险点变成可信执行单元。
