2、镜像供应链基础：容器镜像生命周期、镜像仓库（Harbor/Docker Registry）、镜像签名与验证机制
2.1 容器镜像生命周期
容器镜像从构建到运行结束，经历一个完整的生命周期。理解每个阶段的安全控制点，是构建镜像供应链信任边界的前提。
| 阶段 | 关键活动 | 安全风险 | 信任控制点 |
|---|---|---|---|
| 构建 | Dockerfile 编写、基础镜像拉取、层叠加 | 基础镜像投毒、恶意依赖、构建缓存污染 | 基础镜像签名验证、依赖扫描、构建环境隔离 |
| 分发 | 镜像推送至仓库、标签管理、跨环境同步 | 中间人篡改、仓库凭证泄露、镜像覆盖 | TLS 传输加密、镜像签名、仓库访问控制 |
| 存储 | 镜像层持久化、垃圾回收、版本保留 | 存储侧篡改、未授权拉取、过期漏洞镜像 | 存储加密、不可变标签、漏洞扫描策略 |
| 部署 | 镜像拉取、容器运行时创建、配置注入 | 运行恶意镜像、配置泄露、提权攻击 | 部署前签名验证、准入控制、运行时安全策略 |
| 运行 | 容器进程执行、网络通信、日志采集 | 逃逸攻击、资源滥用、敏感信息泄露 | 运行时监控、行为基线、不可变基础设施 |
| 退役 | 镜像下线、层清理、审计归档 | 残留数据泄露、未清理的漏洞镜像 | 镜像保留策略、审计日志、安全删除 |
关键原则：镜像供应链信任不是单一环节的加固，而是从构建到退役的全链路持续验证。每个阶段都必须建立可审计的信任锚点。
2.2 镜像仓库：Harbor 与 Docker Registry
镜像仓库是镜像供应链的核心枢纽，负责镜像的存储、分发和访问控制。生产环境中，Harbor 和 Docker Registry 是最主流的两种选择。
2.2.1 Docker Registry
Docker Registry 是 Docker 官方的开源镜像存储服务，提供基础的镜像推送、拉取和存储能力。
- 架构：无状态 API 层 + 后端存储（本地文件系统、S3、GCS、Azure Blob 等）。
- 认证：支持 认证和 Basic Auth，但无内置用户管理。
- 安全特性：支持 TLS 加密、签名验证（Notary 集成）、垃圾回收。
- 适用场景：小型团队、开发测试环境、需要高度自定义的场景。
2.2.2 Harbor
Harbor 是 CNCF 毕业项目，在 Docker Registry 基础上增加了企业级安全、管理和合规能力。
| 特性 | Docker Registry | Harbor |
|---|---|---|
| 用户管理 | 无内置用户系统 | LDAP/AD/OIDC 集成，RBAC 权限模型 |
| 镜像复制 | 手动脚本 | 基于策略的跨地域/跨集群自动同步 |
| 漏洞扫描 | 需第三方集成 | 内置 Trivy/Clair 扫描引擎 |
| 签名与验证 | Notary 独立部署 | 内置 Cosign 集成，支持 OCI 签名 |
| 不可变标签 | 不支持 | 支持，防止标签覆盖 |
| 审计日志 | 无 | 全操作审计日志 |
| Webhook | 无 | 支持事件触发，集成 CI/CD |
生产建议：企业级镜像供应链必须选择 Harbor 或类似具备 RBAC、扫描、签名能力的仓库。Docker Registry 仅适合作为开发测试的轻量级缓存节点。
2.3 镜像签名与验证机制
镜像签名是确保镜像从构建到部署全链路完整性和来源可信的核心技术。没有签名的镜像，无法区分是开发者发布的合法镜像还是攻击者篡改的恶意镜像。
2.3.1 签名原理
镜像签名基于非对称加密：开发者使用私钥对镜像摘要（Digest）进行签名，验证者使用对应的公钥验证签名是否匹配。
# 使用 Cosign 对镜像进行签名（示例）
# 生成密钥对
cosign generate-key-pair
# 对镜像进行签名
cosign sign --key cosign.key registry.example.com/myapp:v1.0
# 验证镜像签名
cosign verify --key cosign.pub registry.example.com/myapp:v1.02.3.2 主流签名标准
| 标准/工具 | 签名格式 | 密钥管理 | 仓库集成 | 适用场景 |
|---|---|---|---|---|
| Docker Content Trust (DCT) | Notary v1 | 本地 Yubikey/文件 | Docker Registry | 传统 Docker 环境 |
| Cosign | OCI 签名（Sigstore） | 密钥对、KMS、OIDC | Harbor、Docker Registry、GitHub Container Registry | 现代云原生、GitOps |
| Notation | OCI 签名（Notary v2） | 证书、KMS | Harbor、Azure Container Registry | 企业 PKI 集成 |
2.3.3 验证策略
验证不是一次性的操作，而是贯穿镜像供应链的持续策略：
- 构建时验证：CI 流水线拉取基础镜像时，验证基础镜像的签名是否来自可信发布者。
- 推送时验证：Harbor 接收推送请求时，验证镜像是否携带有效签名，拒绝未签名镜像。
- 部署时验证：Kubernetes 准入控制器（如 Kyverno、OPA Gatekeeper）在创建 Pod 前验证镜像签名。
- 运行时验证：运行时安全工具持续监控容器文件系统，检测镜像层是否被篡改。
常见误区：签名不是一次性的“盖章”。密钥轮换、签名过期、撤销列表管理是签名体系中最容易被忽视的运维负担。建议使用 Sigstore 的 OIDC 临时密钥模式，减少长期密钥管理风险。
2.4 镜像供应链信任边界架构
下图展示了从镜像构建到部署的完整信任边界，以及签名与验证机制在各个环节的嵌入位置。
2.5 信任边界的关键实践
核心原则：信任不是继承的，而是每次交互时重新验证的。即使基础镜像来自官方仓库，每次构建和部署时都必须重新验证其签名和完整性。
- 最小签名策略：只对生产环境部署的镜像强制签名验证，开发环境可放宽策略。
- 密钥分级：开发密钥、测试密钥、生产密钥分离，生产密钥必须存储在 KMS 或 HSM 中。
- 签名覆盖范围：不仅签名最终镜像，基础镜像、依赖层、SBOM（软件物料清单）也应签名。
- 自动化验证：将签名验证嵌入 CI/CD 流水线，拒绝未签名或签名验证失败的镜像进入下一阶段。
- 定期审计：定期检查签名策略执行情况、密钥使用记录和镜像仓库的访问日志。
推荐工具链：Harbor + Cosign + Kyverno 是目前最成熟的镜像供应链信任栈。Harbor 提供仓库级 RBAC 和扫描，Cosign 提供 OCI 签名，Kyverno 提供 Kubernetes 准入控制。