2. Harbor 基础回顾：架构、核心组件与部署模式
在深入镜像签名与准入控制之前，有必要重新梳理 Harbor 的整体架构。Harbor 并非单一二进制，而是一组微服务协作的产物。理解每个组件的职责与通信方式，是后续配置签名策略、调试准入校验失败问题的前提。
2.1 整体架构概览
Harbor 采用前后端分离、微服务化的设计。用户通过 Core 服务发起操作，Registry 负责镜像存储，Jobservice 处理异步任务（如复制、扫描、签名）。所有组件共享同一个数据库（PostgreSQL）和缓存（Redis）。
架构要点：Core 是所有请求的入口，Registry 不直接暴露给外部；Jobservice 负责所有后台任务，包括镜像签名。签名操作由 Jobservice 调用
cosign 或 notation 完成，结果存储在 Registry 的 OCI 制品中。
2.2 核心组件详解
下表列出了 Harbor 核心组件及其在镜像签名与准入控制场景中的关键作用：
| 组件 | 主要职责 | 签名/准入相关功能 |
|---|---|---|
| Core | API 网关、UI、认证授权、项目管理 | 触发签名策略、校验用户权限、管理签名密钥、提供 Webhook 事件 |
| Registry | OCI 镜像存储与分发（基于 Docker Distribution） | 存储签名制品（如 .sig 标签）、支持 OCI Artifact Manifest |
| Jobservice | 异步任务调度与执行 | 执行镜像签名任务、执行漏洞扫描、执行复制任务 |
| Trivy / Scanner | 漏洞扫描（可选组件） | 扫描结果可作为准入策略的判断条件 |
| Database (PostgreSQL) | 元数据持久化 | 存储签名策略配置、项目设置、审计日志 |
| Cache (Redis) | 会话缓存、任务队列 | 加速 Webhook 分发、任务排队 |
2.3 部署模式对比
Harbor 支持多种部署模式，不同模式对签名与准入控制的影响主要体现在网络拓扑和证书管理上。
- 在线安装模式（Online Installer）：通过
install.sh脚本部署，适合单机或小规模测试环境。签名功能需手动启用 Notary 或 Cosign 集成。 - 离线安装模式（Offline Installer）：包含所有镜像包，适合内网环境。签名密钥的管理需提前规划。
- 高可用模式（HA / Helm Chart）：基于 Kubernetes 部署，支持多副本、负载均衡。签名任务由 Jobservice 分布式执行，需确保共享存储（如 S3）的一致性。
部署注意事项：如果计划在生产环境启用镜像签名准入控制，强烈建议使用 Helm Chart 高可用模式。单机模式下 Jobservice 是单点，签名任务失败可能导致镜像推送阻塞。同时，确保所有节点的时间同步（NTP），因为签名验证依赖时间戳。
2.4 组件通信流程（签名场景）
当用户推送镜像并触发自动签名时，组件间的交互顺序如下：
- 用户推送镜像：
docker push请求到达 Core，Core 验证用户身份与项目权限。 - Core 转发至 Registry：Core 生成临时 ，允许用户将镜像层数据写入 Registry。
- Webhook 触发：Registry 推送完成后，通过 Webhook 通知 Core 镜像已就绪。
- Core 创建签名任务：Core 根据项目策略，向 Jobservice 提交一个签名任务。
- Jobservice 执行签名：Jobservice 拉取镜像，调用
cosign sign或notation sign，将签名结果推送回 Registry（作为 OCI Artifact）。 - 状态回写：Jobservice 将签名状态（成功/失败）写入 Database，Core 通过 API 返回给用户。
关键路径：签名操作不阻塞镜像推送流程。用户推送完成后立即得到响应，签名在后台异步执行。准入控制（如
kube-apiserver 的校验）在拉取阶段检查签名是否存在且有效。