镜像仓库与供应链

• OCI Distribution Spec 定义分发协议
• blob 与 manifest 的分离
• push/pull 流程

OCI Distribution Spec 定义容器镜像的分发协议（registry 的 HTTP API）。核心概念：镜像由 manifest（清单）与 blob（内容）组成。blob 是镜像内容（层、配置），用 digest（sha256）寻址；manifest 描述镜像的层与配置引用。push 流程：客户端先上传 blob（HEAD 检查是否存在，PUT 上传），再上传 manifest 并打 tag。pull 流程：客户端先 GET manifest，再按 manifest 中的引用下载各 blob，校验 digest。规范定义 push/pull 的端点与流程，保证不同工具（docker/containerd/CRI-O）与 registry（Harbor/registry）互操作。OCI 规范让镜像分发标准化。

OCI Distribution Spec 用"manifest 描述 + blob 按 digest 分发"定义 push/pull，实现跨工具与 registry 互操作。

• Image Index 引用多个 manifest
• 多架构（amd64/arm64）分发
• 客户端按平台选择

OCI Image Index（镜像索引）是一个顶层 manifest，引用多个平台特定的 manifest（如 amd64、arm64、Windows 变体）。创建 multi-arch 镜像时，每个平台有独立的 manifest 与 blob，Image Index 列出这些平台 manifest 的引用。客户端（docker/containerd）pull 时先获取 Image Index，根据当前平台（os/arch）选择对应的 manifest 并下载对应 blob。这样同一 tag 可分发到不同架构，实现多架构镜像。配合 docker buildx build --platform 构建多平台。Image Index 是 OCI 的多架构分发机制。

Image Index 引用多个平台 manifest，客户端按平台选择，实现同一 tag 多架构分发。

• 认证方式与机器人账号
• RBAC 角色划分
• 匿名拉取与仓库隔离

镜像仓库认证与权限模型：1) 认证：用户/机器人账号通过 token 认证（Harbor 用 OIDC/本地账号），机器人账号用于 CI 自动化拉取/推送（临时凭据，最小权限）；2) RBAC 角色划分：按角色授权（如 project admin、developer、guest、pull-only），不同角色有不同权限（推/拉/删除/管理）；3) 匿名拉取策略：可配置是否允许匿名拉取（公开镜像），私有镜像需认证；4) 仓库级隔离：按项目（project）/命名空间隔离，不同项目权限隔离，控制每个仓库的访问。权限模型实现最小权限与隔离，保障镜像供应链安全。

仓库权限模型用机器人账号（CI 自动化）、RBAC 角色、匿名拉取策略与项目隔离实现最小权限与访问控制。

• 复制触发（push/定时/手动）
• 断点重试
• 就近拉取加速

镜像仓库异地复制与容灾：1) 复制触发方式：push-based（镜像推送时自动复制到对端）、pull-based（目标端定时从源拉取）、定时调度、手动触发，Harbor 支持基于规则的自动复制；2) 断点重试：复制任务失败时支持断点续传与重试，避免整量重传；3) 跨地域就近拉取加速：在多地部署 registry 副本，或通过复制让就近节点有镜像，客户端从最近节点拉取，降低延迟与带宽；4) 容灾：异地副本保证单点故障时仍可拉取。复制策略需权衡一致性、延迟与存储成本。

异地复制用 push/pull/定时触发，支持断点重试，配合就近拉取实现容灾与加速。

• GC 触发方式（手动/定时）
• 执行流程（清 blob vs 清 tag）
• 未打标签镜像清理

Harbor 垃圾回收（GC）用于清理未被引用的镜像数据（blob），释放存储。触发方式：手动触发（Web UI/API）与定时触发（配置 cron 定时 GC）。执行流程：GC 会扫描镜像仓库，删除未被任何 manifest 引用的 blob（悬空 blob），释放磁盘。需注意：删除 tag 时不会立即删 blob，需 GC 才能真正释放存储；GC 期间可能影响拉取（旧版本 Harbor 需谨慎，建议在低峰执行）。未打标签镜像（untagged）清理：Harbor 的保留规则（retention policy）可清理未打标签的镜像与过期 tag，需配合 GC 释放 blob。GC 是仓库体积管理的关键。

Harbor GC 清理未引用 blob 释放存储，需注意触发时机与 delete tag 后 blob 未释放，配合保留规则清理未打标签镜像。

• 扫描工具与 CI 集成
• 漏洞门禁（block 构建）
• 开发者工作流

Snyk/Trivy 等镜像扫描工具嵌入开发者工作流：1) CI 集成：在 CI 流水线（构建后）对镜像运行扫描（trivy image、snyk container test），扫描依赖漏洞、镜像配置；2) 漏洞门禁：设置漏洞阈值（如高危/严重漏洞 >0 则阻断构建/部署），用退出码让 CI 失败（trivy --exit-code 1 --severity HIGH,CRITICAL），实现"有高危漏洞不发布"；3) 开发者工作流：在 PR/commit 阶段扫描、失败反馈给开发者，IDE/CLI 集成让开发者早发现早修复；4) 结果上报：扫描结果接入漏洞管理平台跟踪。门禁设置需平衡安全与开发效率（分级阈值、豁免策略）。

扫描工具嵌入 CI 并设漏洞门禁（高危即阻断），让开发者早发现修复，保障镜像供应链安全。

• TUF 的元数据与角色
• 角色密钥体系（root/targets/snapshot/timestamp）
• 防篡改与防回滚

TUF（The Update Framework）通过角色密钥体系保障软件更新分发安全。它定义多个角色，每个角色有独立密钥：root（信任根，管理其他角色密钥）、targets（目标元数据，描述文件及其哈希）、snapshot（快照，签署 targets 元数据版本）、timestamp（时间戳，指示最新元数据）。各角色密钥分离，root 密钥最高。TUF 元数据签名经哈希校验，防止内容篡改、任意文件投递、回滚攻击（版本号防回滚）、混绑攻击。客户端先验证 root，再验证 timestamp/snapshot/targets，构建信任链。TUF 用于镜像签名（Notation/cosign 也可集成）与软件仓库安全。

TUF 用 root/targets/snapshot/timestamp 四角色密钥分离与签名校验，防篡改、防回滚、防投毒，保障更新分发安全。

• Kraken 的 P2P 分发
• 节点间共享镜像数据
• 大规模分发加速

Kraken 是 Uber 开源的 P2P 镜像分发系统，用于大规模容器镜像分发。原理：镜像数据通过 P2P 在节点间共享，而非所有节点都从中心 registry 拉取。当多个节点需要同一镜像时，已拉取的节点直接向其他节点提供数据（peer-to-peer），减少中心 registry 的带宽与延迟。Kraken 用 tracker 管理数据块位置，节点组成 P2P 网络，配合 hash 校验。收益：大规模集群（数千节点）同时部署时，分发速度大幅提升、中心负载降低。Kraken 适合大规模集群批量拉取镜像的场景。

Kraken 用 P2P 让节点间共享镜像数据，减轻中心 registry 负载，加速大规模分发。

• cosign 签名镜像
• 密钥托管 KMS（云 KMS/HSM）
• 签名与验证流程

cosign 用于容器镜像签名与验证。密钥可托管在 KMS（如 AWS KMS、Azure Key Vault、GCP KMS、HSM），避免私钥明文落地。签名：cosign sign --key aws-kms:///arn:... image，cosign 调 KMS 用托管私钥对镜像（digest）签名，签名作为 OCI 附件（signature）推送到 registry。验证：cosign verify --key aws-kms:///... image，用 KMS 中的公钥/公开密钥验证镜像签名，确认镜像未被篡改、来源可信。KMS 托管收益：密钥安全、可审计、集中管理、可轮换。cosign 是供应链安全（签名镜像）的标准工具。

cosign 用 KMS 托管密钥签名/验证镜像，安全、可审计，签名作为 OCI 附件，是供应链安全标准。

• Rekor 透明日志
• 签名证据记录
• 事后审计

Rekor 是 sigstore 的透明日志（transparency log），记录签名元数据（镜像 digest、签名、公钥、时间戳），追加式、不可篡改。cosign 签名时默认把签名证据提交到 Rekor，生成签名条目与包含时间戳的证书（可用于事后再验证）。通过 Rekor 实现：1) 事后审计：任何人都可查询 Rekor 验证某镜像当时是否被签名、签名时间与签者；2) 防抵赖：签名记录不可篡改，可追溯；3) 时间戳验证：验证签名时间与密钥对的有效性。Rekor 是 sigstore 供应链签名与审计的基础设施。

Rekor 透明日志记录签名证据（不可篡改、可查询），支撑镜像签名的事后审计与防抵赖。

• slim 变体与最小基础镜像
• 多阶段构建
• 缓存清理与去冗余

基于 Debian 构建精简镜像：1) 用 slim 变体（debian:slim）或精简基础镜像（如 debian:bookworm-slim、distroless），去掉不必要的包与文档；2) 多阶段构建：用完整 Debian 构建（编译、安装依赖），最终阶段只拷贝运行所需，不包含构建工具；3) 缓存清理：apt 安装后清理缓存（rm -rf /var/lib/apt/lists/*）、清理临时文件、合并 RUN 减少层；4) 去冗余：只装运行依赖（--no-install-recommends）、删除不需要的软件包。组合可显著减小镜像体积，降低攻击面与传输成本。

精简 Debian 镜像用 slim 基础、多阶段构建、apt 缓存清理与最小依赖，是常见的镜像瘦身实践。

• latest 是可变标签
• 不可复现与漂移
• 反模式与替代

latest 标签是反模式：1) 不可复现：latest 指向不断变化的镜像，不同时间部署的 latest 内容不同，无法复现一致部署；2) 漂移风险：latest 更新后，旧部署无法追溯确切版本；3) 供应链审计困难：无法确定部署的具体镜像；4) 误用：latest 可能被误认为"最新稳定版"，实际可能是测试版。替代：使用明确的语义化版本 tag（如 1.2.3）或不可变 digest，生产锁定具体版本/digest，latest 仅用于开发便捷。最佳实践是"版本化 + 不可变 digest + 灰度"。

latest 可变导致不可复现与漂移，是反模式，生产应使用版本 tag 或 digest 精确部署。

• Harbor 的容器专有功能
• Nexus 的通用制品
• 云仓库（ECR/ACR）等

镜像仓库选型：1) Harbor：CNCF 项目，容器镜像专有，提供 RBAC、漏洞扫描、签名、复制、GC、审计、镜像仓库策略，适合企业私有镜像治理；2) Nexus：通用制品仓库（Maven/npm/pypi/mirror 等），也可存容器镜像，但容器功能（扫描/签名/复制）不如 Harbor 深度；3) 云仓库：AWS ECR、Azure ACR、阿里云 ACR 等，托管、免运维、与云服务集成（IAM、扫描、复制），适合云原生环境；4) 自建 vs 托管：自建可控但需运维，托管控成本但受厂商约束。选型按企业治理需求、生态集成、合规与成本。

选型按功能（Harbor 容器专有、Nexus 通用、云仓库托管）与治理/成本权衡，Harbor 适合企业镜像治理。

• 本地盘性能与扩容限制
• 对象存储可扩展与 GC 特点
• 分布式文件系统

镜像仓库存储后端选型：1) 本地盘：性能高（近盘读写）、部署简单，但容量受单机限制、扩容需加盘、GC 直接删本地文件，适合小规模；2) 对象存储（S3/minio/OSS）：可无限扩展、按需扩容、持久化好，Harbor 支持对象存储后端，GC 通过对象删除实现，但性能受对象存储延迟影响，适合大规模与云环境；3) 分布式文件系统（共享存储）：多节点共享、高可用，但运维复杂、性能与扩容需规划。选型按规模、性能、扩容与运维成本：大规模与云用对象存储，小规模用本地盘，需共享高可用用分布式。

存储后端按规模/性能/扩容权衡：本地盘性能好但扩展受限，对象存储可扩展性佳，分布式高可用但复杂。

• Flux ImagePolicy/ImageRepository
• 自动检测新标签
• 更新 Git 清单（GitOps）

Flux 的 Image Update Automation 实现 GitOps 式镜像自动更新：1) 定义 ImageRepository（监控仓库的镜像 tag）与 ImagePolicy（选择策略，如 semver 语义化版本、latest、regex）；2) Flux 定期扫描镜像仓库，检测匹配策略的新标签；3) 当有新镜像 tag 时，ImageUpdateAutomation 用指定方式更新 Git 清单中的镜像引用（如 kustomize 的 image 字段、YAML 的镜像 tag），并提交到 Git 仓库；4) 再由 Flux 的 Kustomization/HelmRelease 应用到集群，实现"新镜像自动更新到 Git 并部署"。实现镜像自动升级的 GitOps 闭环，可审计、可回滚。

Flux 用 ImageRepository/ImagePolicy 检测新标签，ImageUpdateAutomation 自动更新 Git 清单并应用，实现 GitOps 镜像自动升级。

• 高可用部署（多副本/负载均衡）
• 多租户隔离
• 认证与配额

镜像仓库高可用与多租户：1) 高可用：多副本部署（如 Harbor 多实例）+ 负载均衡（共享数据库/Redis/对象存储），单个节点故障不影响服务；存储用对象存储/共享存储保证数据高可用；2) 多租户：按项目（project）/命名空间隔离租户，不同租户互不可见，RBAC 控制每个租户的权限；3) 认证与配额：各租户独立认证（OIDC/本地账号），可配置存储配额（quota）限制每个项目的镜像空间，加审计日志。高可用+多租户让仓库支持多团队安全共享，是企业级镜像仓库的必备。

高可用（多副本+共享存储）与多租户（项目隔离+RBAC+配额）是企业级镜像仓库的关键能力。

• GC 清理未引用 blob
• 保留策略清理过期 tag
• 生命周期管理

镜像清理与生命周期管理：1) GC（垃圾回收）：清理未被引用的 blob（悬空数据），释放存储（如 Harbor 的 GC、registry 的 GC）；2) 保留策略（retention policy）：按规则清理过期/未使用的镜像 tag（如保留最近 N 个、按时间清理、清理未打标签镜像），防止仓库无限增长；3) 生命周期：结合 tag 策略（版本化、清理旧版本）与镜像扫描，管理镜像从发布到回收的全过程。落地：配置定时 GC + 保留规则，监控存储使用，避免仓库膨胀。清理策略需与部署需求平衡（保留可回滚版本）。

镜像清理是"GC 清 blob + 保留策略清 tag + 生命周期管理"，定时执行防仓库膨胀，兼顾可回滚。

• Trivy 与 Clair 的扫描原理
• 漏洞数据库与检测
• 扫描集成

镜像漏洞扫描工具：Trivy：轻量、快，扫描镜像的软件包（OS 包、语言依赖）与漏洞库（CVE）比对，输出漏洞与严重级别，支持 CLI/CI 集成与退出码门禁，是主流扫描工具。Clair：CoreOS 开源的镜像漏洞分析器，通过比对镜像软件包与漏洞数据库，常集成到 Harbor 等仓库做静态扫描。两者都基于"镜像软件包清单 vs 漏洞库"比对。集成：Trivy 在 CI 扫描+门禁，Clair 在 Harbor 仓库扫描。扫描用于发现镜像漏洞，指导修复与门禁，是供应链安全关键。

Trivy/Clair 通过比对镜像软件包与漏洞库发现 CVE，Trivy 轻量 CI 友好、Clair 集成仓库，保障镜像安全。

• Notation 与 cosign 的签名机制
• OCI 附件与签名
• 验证与信任

镜像签名与验证工具：cosign：sigstore 生态，支持 key 与 KMS、keyless 签名（用临时证书+ReKor），签名作为 OCI 附件（signature），cosign verify 验证，是主流签名工具。Notation：微软/CNCF 的签名工具，遵循 OCI 1.1 与 Notary 项目规范，支持多种签名算法（RSA/ECDSA）与 KMS，签名作为 OCI 附件，notation verify 验证，集成信任策略（trust policy）。两者都通过签名+验证保障镜像来源与完整性，防止篡改。选型：cosign 生态广、keyless 方便；Notation 规范正式、企业友好。签名后需在部署端强制验证（准入控制）。

cosign 与 Notation 都对镜像签名（OCI 附件）并验证，cosign 生态广、Notation 规范正式，都用于供应链安全。

• 操作审计日志
• Webhook 事件通知
• 供应链异常告警

镜像仓库审计与事件落地：1) 操作审计日志：记录用户/机器人账号的镜像操作（push/pull/删除/权限变更），Harbor 提供审计日志，可接入 SIEM 汇总，满足合规与追溯；2) Webhook 事件通知：镜像推送/删除/扫描完成等事件通过 Webhook 通知外部系统（如 CI、告警、工单），实现自动化联动；3) 供应链异常告警：对可疑操作（异常 push、未授权拉取、镜像被篡改、高危漏洞发布）设置告警，结合扫描失败与签名验证失败触发告警，汇集到监控平台。审计+事件+告警形成镜像供应链的可观测与安全闭环。

仓库审计用操作日志、Webhook 事件通知与异常告警，实现供应链可观测与安全闭环。