Dockerfile看起来只是镜像构建脚本，但它会决定镜像里有什么、进程以什么身份运行、依赖是否可追溯、敏感信息是否被带入、运行时权限是否容易收敛。很多容器安全问题并不是部署到Kubernetes后才出现，而是在Dockerfile阶段就已经埋下。
安全Dockerfile的目标不是把每一行写得复杂，而是让镜像更小、更可追溯、更少权限、更容易扫描和更新。对企业团队来说，Dockerfile还应与CI、镜像仓库、漏洞扫描和准入策略连接起来，形成稳定的镜像构建基线。
从可信基础镜像开始
基础镜像决定了大部分系统依赖和漏洞面。生产镜像应优先选择来源可信、维护活跃、版本明确的基础镜像。不要长期使用过旧发行版，也不要为了方便调试把大量工具留在运行镜像中。
推荐做法包括：使用明确版本，不依赖浮动tag作为生产基线；优先选择官方、企业内审或统一维护的基础镜像；对基础镜像建立升级节奏；区分构建镜像和运行镜像，运行镜像只保留必要文件。
FROM golang:1.22 AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build
-o /out/app
./cmd/app
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /out/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]依赖安装要可重复、可审计
不安全的Dockerfile经常在构建时执行不受控下载，例如直接拉取脚本、安装latest依赖或不校验来源。这样的镜像很难复现，也很难解释某次构建为什么引入新漏洞。
更稳妥的方式是锁定依赖版本，使用组织认可的软件源，并在CI中保存SBOM或依赖清单。对于系统包安装，应减少推荐依赖，并在同一层清理缓存，避免把无用索引留在镜像里。
RUN apt-get update &&
apt-get install -y --no-install-recommends ca-certificates tzdata &&
rm -rf /var/lib/apt/lists/*如果业务依赖私有包，不要把访问令牌写进Dockerfile或构建参数后留在镜像层里。应使用构建系统的密钥挂载能力，或由CI在受控环境中注入临时凭据，并确保最终镜像不包含这些信息。
非root运行不是形式要求
默认root运行会放大容器逃逸、文件篡改和错误挂载带来的影响。安全Dockerfile应创建或使用非root用户，并确保应用目录权限与运行身份匹配。
RUN addgroup --system app &&
adduser --system --ingroup app app
WORKDIR /app
COPY --chown=app:app ./dist /app
USER app非root不是单点措施，还要和Kubernetes安全上下文配合，例如禁止特权容器、限制Linux capabilities、使用只读根文件系统、明确临时目录挂载。Dockerfile阶段至少要做到：应用不依赖root写系统目录，日志输出到标准输出，临时文件写入可控路径。
避免把敏感信息写进镜像层
Dockerfile中的每一层都可能被缓存和追溯。即使后续用 rm 删除文件，敏感信息也可能仍存在于历史层中。常见风险包括：复制整个项目目录导致配置文件进入镜像、把私钥写入构建参数、下载私有依赖后未清理凭据、把测试数据或调试脚本留在运行镜像中。
建议维护 .dockerignore，排除本地配置、密钥、Git目录、测试缓存和构建产物。示例：
.git
.env
*.pem
node_modules
coverage
tmp同时，在镜像入库前执行密钥扫描和漏洞扫描。安全不是靠开发者记忆每个细节，而是通过构建模板、扫描门禁和仓库策略形成默认保护。
把Dockerfile安全纳入供应链治理
企业镜像安全不能只靠单个Dockerfile优化。更完整的链路应包括源码依赖审计、构建环境隔离、镜像扫描、签名、仓库权限和部署准入。对于Kubernetes环境，Dockerfile安全还应和容器镜像安全治理联动：镜像越标准，运行时策略越容易落地；镜像越混乱，平台侧就越难判断哪些权限是必要的。
发布前可以逐项自查：基础镜像是否明确版本；是否使用多阶段构建；是否只复制必要文件；是否有 .dockerignore；是否避免在镜像层写入密钥；是否使用非root用户；是否清理包管理器缓存；是否输出日志到标准输出；是否可以被漏洞扫描工具识别；是否能在Kubernetes受限安全上下文中运行。
常见问题
使用Alpine基础镜像一定更安全吗？
不一定。Alpine体积小，攻击面通常较小，但也可能带来glibc兼容、调试困难和依赖适配问题。安全性应综合考虑维护频率、漏洞修复速度、业务兼容性和团队运维能力。对于某些语言运行时，Debian slim、Ubuntu minimal或distroless可能更合适。关键是统一基线、持续扫描和及时升级。
Dockerfile里写 USER 后就足够安全吗？
不够。非root运行是重要基础，但还需要文件权限、运行时安全上下文、只读根文件系统、capabilities控制、网络策略和Secret管理配合。如果应用仍然需要写系统目录、挂载宿主机路径或使用特权模式，单独写 USER 很难提供完整保护。应把Dockerfile安全和Kubernetes部署配置一起评审。
为什么不建议在Dockerfile中直接下载远程脚本执行？
因为这会降低构建可追溯性和供应链可信度。远程脚本内容可能变化，下载链路可能被劫持，构建结果也难以复现。若确实需要下载外部组件，应固定版本、校验摘要、使用可信源，并在CI中保存构建证据。更推荐把依赖纳入包管理或内部制品库统一治理。
