dockerfile必须通过user、--chown、run删险工具等可执行指令固化最小权限，确保非root用户生效且不可绕过，并配合运行时参数实现能力裁剪与只读约束。
直接在 Dockerfile 中定义业务安全准入规则，不是加个注释或写句说明，而是通过可执行、可验证的指令组合，把权限控制、运行环境约束和最小化原则固化进镜像构建过程。关键不在“有没有”，而在“是否生效且不可绕过”。
明确声明非 root 用户并确保其生效
Dockerfile 中的 USER 指令必须出现在所有需要写入文件的操作之后、容器启动前，并且不能被后续 RUN 指令意外覆盖。Hadolint 的 DL3002 规则会检测最后一条 USER 是否为 root 或 0，但真正起作用的是最终 ENTRYPOINT 或 CMD 执行时的上下文。
- 先创建用户组和用户，再 chown 复制的文件： RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001
- 复制应用文件时直接归属目标用户： COPY --chown=appuser:appgroup ./dist/ /app/
- 切换用户后，禁止任何后续 RUN 使用 root 权限： USER appuser（放在 Dockerfile 末尾，紧邻 CMD/ENTRYPOINT）
限制运行时能力与系统调用面
Dockerfile 本身不直接配置 seccomp 或 capabilities，但它决定了基础镜像是否支持这些策略落地。你需配合运行时参数使用，而 Dockerfile 要为这种配合做好准备：
- 选择精简基础镜像（如 alpine:3.18 或 gcr.io/distroless/base），避免自带危险工具（bash、curl、netcat 等）
- 移除不必要的二进制文件（尤其 shell 和包管理器）： RUN apk del --purge bash ca-certificates && rm -rf /var/cache/apk/*
- 显式声明只读挂载意图（虽由 docker run 控制，但 Dockerfile 可标注）： # STAGE: runtime — filesystem must be read-only at runtime
固化只读路径与敏感目录隔离
容器内业务不应具备修改自身代码、配置或日志目录的能力。Dockerfile 可通过结构设计提前规避风险：
- 将静态资源、配置、二进制分离存放，仅开放 tmpfs 或 volume 映射点：
WORKDIR /app（只放可执行文件）
VOLUME ["/tmp", "/run"]（显式声明可写位置） - 禁止在镜像中写入日志到磁盘： ENV LOG_DIR=/dev/stdout，并让应用直接输出到 stdout
- 删除默认挂载点残留（如 /proc、/sys 不应在构建阶段被访问）： RUN rm -f /proc/* /sys/* /dev/*（仅对构建层有效，运行时仍由 kernel 提供）
嵌入可信校验与构建时安全断言
安全准入不仅是运行态约束，更应延伸至构建环节。Dockerfile 可主动引入校验逻辑，使“不安全构建”直接失败：
- 校验下载文件的 SHA256（比单纯 curl 更可靠）： RUN wget -O app.tgz https://example.com/app-v2.3.tgz && echo "a1b2c3... app.tgz" | sha256sum -c -
- 拒绝使用 latest 标签，强制绑定 digest： FROM alpine@sha256:7a9b2e4f...
- 扫描当前镜像层漏洞（需集成 Trivy CLI）： RUN trivy fs --exit-code 1 --severity CRITICAL, HIGH .（CI 中启用，本地构建可选）
