4. 镜像构建最佳实践：最小化基础镜像、多阶段构建、减少层数、避免敏感信息写入

镜像构建是容器安全链的起点。一个不安全的镜像会在后续的部署、运行时持续暴露风险。本章聚焦于四项核心构建实践，它们能显著降低攻击面、减小镜像体积、提升构建效率，并防止敏感数据泄露。

核心原则：镜像越小，攻击面越小；层数越少，扫描与传输越快；敏感信息一旦写入镜像层，即使后续删除也无法彻底清除。

4.1 最小化基础镜像

基础镜像的选择直接决定了镜像的初始体积和潜在漏洞数量。一个包含完整操作系统、编译器、调试工具的基础镜像（如 ubuntu:22.04 或 centos:8）通常体积在 200MB 以上，且包含大量非运行时必需的软件包。

基础镜像类型 典型体积 漏洞数量（参考） 适用场景
ubuntu:22.04 ~200 MB 高（数百个） 通用开发、需要完整工具链
alpine:3.19 ~7 MB 低（数十个） 生产环境、微服务、静态编译应用
distroless ~20-50 MB 极低（个位数） 高安全要求、无 shell 需求
scratch 0 MB 0 纯静态二进制、Go/Rust 应用
推荐策略：优先选择 alpine 或 distroless 作为生产基础镜像。对于 Go、Rust 等静态编译语言，直接使用 scratch 是最佳选择。

4.2 多阶段构建

多阶段构建允许在同一个 Dockerfile 中使用多个 FROM 指令，将构建环境与运行环境彻底分离。构建阶段可以包含完整的编译器、依赖库和测试工具，而最终运行阶段只复制必要的二进制文件和运行时依赖。

# 第一阶段：构建阶段
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o myapp .

# 第二阶段：运行阶段
FROM alpine:3.19
RUN apk add --no-cache ca-certificates tzdata
COPY --from=builder /app/myapp /usr/local/bin/myapp
EXPOSE 8080
USER 1001
ENTRYPOINT ["myapp"]

上述示例中，最终镜像仅包含 alpine:3.19 基础层、ca-certificates 和 tzdata 包、以及编译好的二进制文件，体积从构建阶段的 1.2GB 缩减至约 20MB。

注意：多阶段构建中，COPY --from 只会复制指定路径的文件，不会复制构建阶段的层历史。这天然避免了构建工具和临时文件的残留。

4.3 减少层数

Docker 镜像由只读层叠加而成。每一条 RUN、COPY、ADD 指令都会创建一个新层。过多的层数不仅增加镜像体积，还会降低镜像拉取和扫描效率。

层数优化规则：

  • 合并 RUN 指令：使用 && 连接多个命令，并在最后清理缓存。
  • 谨慎使用 ADD：优先使用 COPY，除非需要自动解压 tar 包或远程 URL 下载。
  • 避免不必要的 COPY：使用 .dockerignore 排除无关文件。
# 不推荐：产生 4 层
RUN apt-get update
RUN apt-get install -y python3
RUN apt-get clean
RUN rm -rf /var/lib/apt/lists/*

# 推荐：合并为 1 层
RUN apt-get update && \
    apt-get install -y python3 && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

合并后的层数从 4 层减少到 1 层，且中间缓存文件不会保留在最终镜像中。

4.4 避免敏感信息写入

敏感信息（密码、、SSH 私钥、令牌等）一旦写入镜像层，即使后续通过 RUN rm 删除，该信息仍然存在于镜像历史中。任何能够访问镜像的人都可以通过 docker history 或层导出工具提取这些数据。

常见错误示例：

# 危险！密钥会永久留在镜像层中
FROM alpine:3.19
RUN echo "AKIAIOSFODNN7EXAMPLE" > /tmp/secret.txt
RUN rm /tmp/secret.txt
# 密钥仍然可以通过 docker history 查看

安全替代方案：

  • 构建时使用 ARG：通过 --build-arg 传递，但注意 ARG 值会保留在镜像历史中（除非使用多阶段构建且 ARG 只在构建阶段使用）。
  • 运行时使用环境变量或 Secret 管理：通过 docker run -e、Kubernetes Secrets、Vault 等注入。
  • 使用 BuildKit 的 --secret 功能：构建时挂载敏感文件，不写入镜像层。
# 使用 BuildKit 安全传递 SSH 密钥
# docker build --ssh default --secret id=mysecret,src=./secret.txt -t myapp .
FROM alpine:3.19
RUN --mount=type=secret,id=mysecret \
    cat /run/secrets/mysecret > /tmp/secret.txt && \
    # 使用密钥进行操作，然后删除
    rm /tmp/secret.txt
黄金法则：永远不要在 Dockerfile 中硬编码任何敏感信息。使用构建时 Secret、运行时环境变量或外部 Secret 管理服务。

4.5 综合实践流程

以下 SVG 图展示了从代码提交到安全镜像产出的完整构建流程，整合了上述四项最佳实践。

镜像构建安全最佳实践综合流程 代码提交 选择最小基础镜像 (alpine/distroless) 多阶段构建 (Builder → Runtime) 合并 RUN 指令 | 使用 BuildKit Secret | 清理缓存 安全镜像产出 (小体积 + 低漏洞) 说明：每个环节都直接贡献于镜像安全。最小基础镜像减少攻击面，多阶段构建分离环境，层数优化降低体积，Secret 管理防止泄露。

4.6 实践检查清单

在构建流水线中集成以下检查点，确保每项最佳实践得到落实：

检查项 验证方法 自动化工具
基础镜像是否为最小化版本 检查 FROM 指令，对比体积 dive、docker images
是否使用多阶段构建 检查 Dockerfile 中 FROM 数量 hadolint 规则 DL3022
层数是否合理（建议 < 20） docker history 查看层数 dive、docker scout
是否包含敏感信息 扫描镜像历史中的字符串 trivy、grype、docker history
是否使用 .dockerignore 检查构建上下文大小 docker build 输出
自动化集成建议：在 CI/CD 流水线中集成 hadolint 进行 Dockerfile 静态分析，使用 dive 分析镜像层效率，使用 trivy 或 grype 扫描最终镜像的漏洞和敏感信息。

通过严格执行上述四项最佳实践，镜像体积可减少 80%-95%，漏洞数量降低 90% 以上，同时彻底消除敏感信息泄露风险。这些实践是构建安全容器化应用的基础，也是后续自动化安全扫描和运行时防护的前提。

← 上一章 📖 返回目录 下一章 →