📚 课程目录第2章 Harbor架构深度解析

2. Harbor 架构深度解析：核心组件、数据流与信任锚点

Harbor 并非单体应用，而是一组微服务协作构成的镜像供应链控制平面。理解其核心组件、数据流转路径以及信任锚点的建立方式，是设计安全策略与进行故障排查的基础。本章将拆解 Harbor 的内部架构，并聚焦于信任链的建立点。

Harbor 由多个独立容器化服务组成，每个服务承担特定职责。下表列出了主要组件及其在信任链中的角色：

组件	核心职责	信任锚点角色
Core	API 网关、用户认证、RBAC、项目管理、Webhook、审计日志	身份与策略决策点（PDP），签发会话
Registry	OCI 镜像存储、分发、Blob 与 Manifest 管理	制品存储与签名验证执行点
JobService	异步任务调度：镜像复制、GC、漏洞扫描、标签清理	跨集群信任传播的执行引擎
ChartMuseum	Helm Chart 的存储、版本管理与上传下载	K8s 应用包签名与验证锚点
Trivy / Scanner	镜像漏洞扫描、CVE 报告生成	内容安全评估的信任数据源
Notary	镜像内容签名与验证（Docker Content Trust）	端到端签名信任链的根
Database (PostgreSQL)	持久化用户、项目、策略、扫描结果等元数据	信任状态存储
Redis	会话缓存、任务队列、JobService 锁	临时信任凭证缓存

架构要点： Core 是所有请求的入口，Registry 是制品的最终存储地，而 JobService 是异步信任动作（如复制到远端仓库并携带签名）的调度中心。三者构成 Harbor 信任控制平面的铁三角。

一次完整的镜像推送与信任验证流程，展示了组件间的协作关系。以下为典型的数据流路径：

客户端认证： Docker/containerd 客户端向 Core 发起登录请求，Core 验证凭证后返回 Bearer 。
Manifest 上传： 客户端携带向 Registry 推送镜像 Manifest。Registry 通过向 Core 验证权限。
Blob 流式上传： 镜像层（Blob）被分块上传至 Registry，Registry 计算摘要并存储。
扫描触发： Registry 完成 Manifest 接收后，通过消息队列通知 JobService。
异步扫描： JobService 调度 Trivy 扫描器拉取镜像层，生成漏洞报告并写回数据库。
签名（可选）： 若项目启用内容信任，客户端在推送后调用 Notary 服务对镜像 Tag 进行签名，签名元数据存储在 Notary Server 中。
策略评估： 当客户端拉取镜像时，Core 根据项目策略（如“仅允许已签名且无高危漏洞的镜像”）查询 Notary 和 Trivy 结果，决定是否允许拉取。

  信任锚点关键路径： 步骤 6 和 7 是信任链的核心。Notary 提供签名锚点，Trivy 提供安全锚点，Core 作为策略引擎将两者结合，形成“签名 + 扫描”的双重信任决策。

信任锚点并非单一节点，而是分布在 Harbor 的多个组件中。下图展示了信任锚点的逻辑分布与交互关系：

组件间的通信并非全信任模式，而是通过明确的身份验证与加密通道实现信任传递：

Core ↔ Registry： Registry 通过 Core 的验证接口确认用户权限，两者之间使用内部 mTLS 或共享密钥。
JobService ↔ Registry/Trivy： JobService 使用内部服务账户调用 Registry 拉取镜像，并调度 Trivy 执行扫描，扫描结果通过 API 写回 Core。
Notary ↔ Core： Notary 独立部署，Core 通过 Notary 的 API 查询签名状态，两者之间使用 TLS 加密。
ChartMuseum ↔ Core： ChartMuseum 复用 Core 的认证，上传/下载 Chart 时由 Core 进行权限校验。

安全注意事项： 在分布式部署中，所有组件间的通信必须启用 TLS。默认情况下，Harbor 内部使用 HTTP 通信，生产环境必须通过反向代理或 Service Mesh 强制加密。此外，Notary 的根密钥和仓库密钥应离线存储，避免泄露导致信任链崩溃。

Harbor 的信任体系可抽象为三层锚点模型，每一层解决不同维度的信任问题：