4. 容器镜像基线：Dockerfile 最佳实践、基础镜像版本锁定、多阶段构建、镜像扫描与签名校验
容器镜像是平台工程中应用交付的核心载体。镜像的构建方式、基础镜像选择、构建阶段优化以及安全校验直接决定了环境一致性、部署速度和运行时安全。本章围绕容器镜像基线，从 Dockerfile 编写规范到镜像签名校验，建立一套可审计、可复现的基线核验流程。
4.1 Dockerfile 最佳实践
Dockerfile 的编写质量直接影响镜像构建缓存命中率、层数、安全性和可维护性。以下基线规则应在平台工程中强制落地：
| 实践项 | 基线要求 | 核验方式 |
|---|---|---|
| 指令顺序 | 按变更频率从低到高排列（FROM → WORKDIR → COPY package.json → RUN npm install → COPY .） | Dockerfile lint（hadolint） |
| 层数控制 | 合并 RUN 指令，减少镜像层数；单层不超过 100 层 | docker history 检查 |
| 非 root 运行 | 使用 USER 指令切换到非 root 用户 |
镜像运行时进程 UID 检查 |
| 清理缓存 | 在 RUN 指令末尾删除包管理器缓存（apt-get clean / npm cache clean --force） |
镜像层大小对比 |
| 标签规范 | 禁止使用 latest；必须使用语义化版本 + Git commit SHA |
镜像仓库标签审计 |
基线核验点： 平台工程团队应在 CI 流水线中集成 hadolint 对 Dockerfile 进行静态检查，违反上述规则的构建应被阻断。
4.2 基础镜像版本锁定
基础镜像的版本漂移是环境不一致的首要来源。平台工程必须强制锁定基础镜像的完整摘要（digest），而非仅依赖标签。
- 标签问题：
node:18或python:3.11-slim会随上游更新而指向不同镜像，导致构建结果不可复现。 - 锁定方式： 使用
FROM node:18@sha256:abc123...格式，确保每次拉取的是同一镜像内容。 - 更新策略： 通过自动化工具（如 Renovate、Dependabot）定期扫描基础镜像更新，生成 PR 并触发重新构建和测试。
常见陷阱： 即使锁定了 digest，基础镜像的底层操作系统包（如 glibc、openssl）仍可能因上游重建而包含安全补丁。平台工程应建立基础镜像的定期重新构建机制，而非永久锁定不变。
4.3 多阶段构建
多阶段构建是减少最终镜像体积、消除构建依赖和敏感信息的核心手段。以下是一个典型的多阶段构建流程：
# 阶段一：构建环境
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server
# 阶段二：运行环境
FROM alpine:3.19@sha256:def456...
RUN apk add --no-cache ca-certificates tzdata
COPY --from=builder /app/server /server
USER 1001
EXPOSE 8080
ENTRYPOINT ["/server"]多阶段构建的基线核验项包括：
- 最终镜像中不应包含编译器、包管理器、源代码文件。
- 构建阶段与运行阶段使用不同的基础镜像，运行阶段应选择最小化镜像（如
alpine、distroless）。 - 敏感信息（如 SSH 密钥、API ）仅在构建阶段使用，不得通过
COPY --from传递到最终阶段。
平台工程建议： 在组织内推广标准化的多阶段构建模板，将构建阶段与运行阶段的基础镜像版本统一管理，减少团队自行选择带来的碎片化。
4.4 镜像扫描
镜像扫描是安全基线的第一道防线。平台工程应在镜像构建完成后、推送至仓库前，自动执行漏洞扫描和合规检查。
| 扫描维度 | 工具示例 | 基线阈值 |
|---|---|---|
| 操作系统漏洞 | Trivy、Grype、Clair | 不允许存在 Critical 级别漏洞；High 级别漏洞数 ≤ 3 |
| 应用依赖漏洞 | Trivy、Snyk、OWASP Dependency-Check | 不允许存在已知 RCE 或数据泄露漏洞 |
| 密钥泄露 | Trivy（secret 扫描）、GitLeaks | 零容忍，发现即阻断 |
| 许可证合规 | Fossology、Scancode | 禁止 GPL 类强传染性许可证用于商业组件 |
流水线集成： 在 CI 的
docker build 之后、docker push 之前插入扫描步骤。扫描结果应生成 JSON 报告并归档，作为镜像元数据的一部分。
4.5 签名校验
镜像签名确保镜像从构建到部署的完整性和来源可信。平台工程应使用 Sigstore/Cosign 或 Notary 建立签名与验证机制。
- 签名时机： 镜像构建并扫描通过后，由 CI 系统使用私钥对镜像摘要进行签名。
- 验证策略： 在 Kubernetes 集群中通过准入控制器（如 Kyverno、OPA Gatekeeper）强制验证镜像签名，未签名或签名无效的镜像拒绝部署。
- 密钥管理： 私钥存储在硬件安全模块（HSM）或云 KMS 中；公钥嵌入集群或通过 OCI 仓库分发。
# 使用 Cosign 签名镜像
cosign sign --key cosign.key ghcr.io/myorg/app:v1.2.3@sha256:abc123...
# 在部署前验证签名
cosign verify --key cosign.pub ghcr.io/myorg/app:v1.2.3@sha256:abc123...4.6 基线核验清单
平台工程团队在评审容器镜像基线时，应逐项核验以下内容：
- Dockerfile 是否通过 hadolint 静态检查，无违规项。
- 基础镜像是否使用完整 digest 锁定，而非仅标签。
- 是否采用多阶段构建，最终镜像体积是否在合理范围内。
- 镜像扫描报告是否归档，Critical 漏洞是否清零。
- 镜像是否经过 Cosign 或 Notary 签名，签名公钥是否已分发至集群。
- Kubernetes 准入控制器是否配置了签名验证策略。
自动化核验： 建议将上述核验项编写为 OPA Rego 策略或 Kyverno ClusterPolicy，在 CI 和 CD 两个阶段自动执行，确保基线不因人为疏忽而偏离。