4. 容器镜像生命周期管理:镜像构建、签名、存储、分发、部署全流程安全要点

容器镜像的安全不能仅依赖最终扫描,而必须贯穿从构建到运行的完整生命周期。任何一个环节的疏漏都可能导致供应链攻击。本章将拆解镜像生命周期的四个核心阶段,并给出每个阶段的安全控制要点与工具实践。

4.1 镜像构建阶段:从源头消除风险

构建阶段是安全左移的第一道防线。基础镜像的选择、依赖引入方式、构建上下文管理都直接影响最终镜像的安全基线。

安全要点 控制措施 推荐工具/策略
基础镜像溯源 仅使用经过签名、哈希校验的官方或内部私有仓库镜像 Docker Content Trust (DCT)、Notary
最小化基础镜像 优先使用 scratch、alpine、distroless 等精简镜像 Google Distroless、Chainguard Images
依赖锁定 使用 package-lock.json、go.sum、requirements.txt 锁定版本 Renovate、Dependabot
构建上下文清理 使用 .dockerignore 排除密钥、日志、.git 目录 手动配置 + CI 检查
多阶段构建 分离构建环境与运行环境,仅复制必要产物 Dockerfile 多阶段语法
实践建议:在 CI 流水线中集成 docker scout 或 trivy 对构建产物进行实时漏洞扫描,若发现 CRITICAL 级别漏洞则直接阻断构建。

4.2 镜像签名与验证:建立信任链

镜像签名确保镜像的发布者身份可验证,且内容在传输过程中未被篡改。Kubernetes 环境可通过策略引擎(如 Kyverno、OPA)强制要求所有部署的镜像必须携带有效签名。

核心流程:开发者使用私钥对镜像摘要签名 → 签名上传至透明日志或 OCI 仓库 → 部署时策略引擎验证公钥与签名 → 验证失败则拒绝 Pod 创建。
# 使用 cosign 对镜像进行签名(示例)
cosign sign --key cosign.key ghcr.io/myorg/myapp:v1.0.0

# 验证签名
cosign verify --key cosign.pub ghcr.io/myorg/myapp:v1.0.0

4.3 镜像存储与分发:保护传输与静态安全

镜像仓库是供应链的核心枢纽。需要同时保障传输加密、访问控制、以及存储层的完整性校验。

  • 传输安全:强制使用 HTTPS 与 OCI 分发规范,禁用 HTTP 回退。
  • 访问控制:基于角色的访问控制(RBAC)限制推送/拉取权限,使用细粒度令牌或 OIDC 集成。
  • 不可变标签:禁止覆盖已有标签(如 latest),强制使用语义版本或 Git SHA 作为标签。
  • 存储加密:对镜像层数据启用静态加密(如 AWS EBS 加密、Azure Storage 加密)。
  • 镜像清理:定期清理未使用的标签和层,减少攻击面与存储成本。
常见陷阱:许多团队在 CI 中直接使用 docker push 到公共仓库,未配置仓库级别的镜像扫描或准入策略。建议所有推送操作前自动触发漏洞扫描,并拒绝推送包含已知高危漏洞的镜像。

4.4 镜像部署与运行时:策略驱动的准入控制

部署阶段是执行安全策略的最后关口。Kyverno 作为 Kubernetes 原生策略引擎,可以在 Pod 创建时拦截并校验镜像的签名、来源、漏洞状态等属性。

# Kyverno 策略示例:强制镜像必须由指定仓库签发
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-signature
    match:
      any:
      - resources:
          kinds:
          - Pod
    verifyImages:
    - imageReferences:
      - "ghcr.io/myorg/*"
      attestors:
      - count: 1
        entries:
        - keys:
            publicKeys: |-
              -----BEGIN PUBLIC KEY-----
              MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
              -----END PUBLIC KEY-----
部署前检查清单:
  1. 镜像是否来自受信仓库?
  2. 镜像是否携带有效签名?
  3. 镜像是否通过最新漏洞扫描(无 CRITICAL 漏洞)?
  4. 镜像是否以非 root 用户运行?
  5. 镜像是否设置了只读根文件系统?

4.5 全流程安全架构图

下图展示了从代码提交到 Pod 运行的完整镜像安全控制链路,以及每个环节对应的策略与工具。

容器镜像全生命周期安全控制链路 ① 构建阶段 基础镜像校验 多阶段构建 ② 签名阶段 cosign / Notary 密钥管理 ③ 存储分发 仓库 RBAC 传输加密 ④ 部署阶段 Kyverno 策略 准入控制 安全控制层:漏洞扫描 · 签名验证 · 策略执行 · 审计日志 工具映射 Trivy / Docker Scout Dockerfile Lint Renovate 工具映射 cosign / sigstore Fulcio / Rekor KMS / Vault 工具映射 Harbor / ECR Notation OCI 分发规范 工具映射 Kyverno / OPA Ratify Admission Webhook 关键策略示例(Kyverno) 1. 禁止使用 latest 标签:imageRegistry: "!*:latest" 2. 强制签名验证:verifyImages: attestors: keys: publicKeys 3. 限制仓库来源:imageRegistry: "harbor.internal/*" 4. 禁止特权容器 + 只读根文件系统:autogen: containers: securityContext

4.6 阶段安全要点总结

阶段 核心风险 关键控制 策略引擎集成点
构建 基础镜像投毒、依赖漏洞 最小化镜像、依赖锁定、多阶段构建 CI 流水线中触发 Trivy 扫描
签名 镜像篡改、发布者身份伪造 cosign 签名、密钥轮换、透明日志 Kyverno verifyImages 规则
存储分发 未授权访问、中间人攻击 仓库 RBAC、HTTPS、不可变标签 仓库 Webhook 通知策略引擎
部署 运行恶意镜像、配置漂移 准入控制、运行时策略、只读文件系统 Kyverno / OPA 强制校验
进阶实践:结合 Ratify 与 Kyverno 实现更细粒度的镜像验证。Ratify 作为外部验证服务,可以同时检查签名、SBOM、漏洞报告等多个属性,Kyverno 则负责调用 Ratify 并执行准入决策。