Harbor 最容易被压缩成一句“私有容器注册表”，这句话在最窄的层面上成立，真正有用的部分却不止于此。项目仓库把 Harbor 描述成一个面向云原生环境的注册表，支持容器镜像与 Helm charts，带有基于 projects 的角色权限控制、基于策略的 replication，以及 vulnerability scanning。[1] CNCF 的项目页把这层意思写得更短，也更准确：Harbor 是一个会存储、签名并扫描内容的开源可信云原生注册表项目。[4] 到了 2026 年，值得重新介绍 Harbor 的原因，已经不在 blob store 本身，而在注册表开始变成一个可治理的分发表面。
截至 2026-05-05T19:04:25Z UTC，GitHub 显示 goharbor/harbor 有 28,426 个 stars、5,218 个 forks、833 个 open issues，最近一次 push 时间为 2026-05-05T09:39:13Z。[2] 当前最新稳定版是 v2.15.0，发布于 2026-03-20；更新的 v2.15.1-rc1 则在 2026-04-29 作为预发布版本出现。[3] 这些数字本身不会替团队做选型，它们至少说明 Harbor 仍然是一条持续演进的运维表面。若一个注册表已经站在 CI、Kubernetes 拉取、跨站点复制和供应链控制的中间位置，这一点就很重要。
图像说明：题图来自 Wikimedia Commons，是汉堡 Altenwerder 集装箱码头的真实照片。[10] 这比 logo 或监控面板截图更贴切，因为 Harbor 真正处理的是物流秩序：哪些制品进来，哪些凭证可以搬运它们，哪些副本要被送往别处，哪些旧制品该在何时退场。
Harbor 的 project 先是权限边界，随后才是一个命名空间
Harbor 最有力量的设计，是它给注册表存储加上了一层清楚的管理形态。README 里写得很直接：用户通过 projects 访问不同的 repositories，而且同一位用户在不同 project 下，对镜像或 Helm charts 可以拥有不同权限。[1] 单看这句话，事情还显得平常；把它和 robot account 文档放在一起之后，真正的结构就出来了。Harbor 支持系统级 robot accounts，这些账户可以覆盖多个 projects，并被定义为用于跨 project 执行操作与 API 调用的 non-user-scoped credentials。[5] 它们不能登录 UI，它们存在的目的，就是替制品搬运和自动化策略提供身份。[5]
这组设计让 Harbor 从“一个推镜像的地方”变成了平台基础设施。一个 project 里可以同时容纳 ownership、pull 与 push 权限、scanner 选择、quota、retention policy 以及自动化凭证。[1][5][8] 很多团队以为自己需要的是自托管注册表，往下做才发现真正需要的是这层治理结构。他们要的并非一个层文件最终落地的地址，而是一个清楚的答案：谁拥有这个命名空间，哪条部署流水线可以拉取它，哪个复制流程有权把它送到别处，怎样避免在 CI 里散落一地的人类账户 token。
这里也构成了 Harbor 的第一条边界。平台团队若希望注册表承担内部产品表面的职责，Harbor 会很有价值。若需求只有一个 repository，用户、环境和制品类别之间几乎没有策略差异，这套系统就显得偏重。
Proxy cache 与 replication，把“依赖上游”改写成一个显式表面
Harbor 的第二个强项，是它不把上游注册表当作一个含混的默认前提，而是当作需要被治理的对象。replication endpoint 文档说明，管理员先定义 endpoints，再为这些 endpoints 配置具备相应权限的访问账户。[9] proxy cache 文档则把边界写得更清楚：proxy cache project 可以拉取目标注册表中，配置账户有权限拉取的所有镜像；任何拥有该 proxy cache project 访问权的 Harbor 用户，也就拥有了这块可见表面。[6] 这句提醒很重要。真正的 trust boundary 是上游访问账户，而并非“cache”这个词带来的轻松感觉。
这正是 Harbor 对企业和严肃自托管团队最有价值的地方。一个注册表常常站在 Docker Hub、GHCR、厂商 registry，或者另一个 Harbor 实例的下游。到了这个阶段，可用性、出口流量、rate limit、地域复制和依赖控制都不再是背景噪音。Harbor 把它们做成了可以配置的对象。README 里说 replication 可以按照 repository、tag 和 label 等 filters 做 policy-based 同步，并在出错时自动 retry。[1] 文档则补上 proxy cache project 的具体形态：它是一类专门 project，不能接受 push，新建时默认带有 7 天 retention policy。[6]
顺着这个角度看，Harbor 把“我们从上游拉取镜像”变成了一件可以被解释的事。哪个账户在拉取？哪些 projects 能看到这块上游表面？哪些镜像需要常驻缓存？哪些制品应该保留，哪些应该随着时间退场？与其让每个集群直接面对公共注册表，再把所有规矩藏在周边脚本里，Harbor 给了平台团队一个更清楚的中间层。
Retention 与 OCI artifact 支持，说明 Harbor 已经离开了 Docker 时代的窄定义
tag retention 文档表面上像一项 housekeeping 功能，真正读进去，能看到 Harbor 对生命周期的理解。它并不让用户直接写“删除规则”，而是让用户定义哪些 artifacts 需要被保留：以 project 为作用域，加上 repository filters、按数量或时间定义阈值，再决定是否把 untagged artifacts 一并纳入。[7] 这里的措辞很有意思。注册表里堆满被后续构建取代的旧制品，不只是整洁度问题，它同时也是存储增长、合规模糊和运维迷雾。Harbor 把 artifact lifecycle 当成产品的一部分来处理。
Harbor 支持的制品形态也早已超出“存镜像”这句老说法。README 依然把 container images 与 Helm charts 放在最显眼的位置。[1] user-defined OCI artifact 文档则把更宽的方向打开了：对于常规镜像之外的 OCI artifacts，Harbor 可以借由自定义 annotations 和 icon layers 展示更丰富的 metadata，连面向机器学习场景的 artifact 类型也能纳入这条路径。[8] 这个做法很稳。注册表依旧围绕 OCI 机制组织，UI 和 metadata 层则被放宽，足以容纳新的制品类别。
这件事在 2026 年很重要，因为平台团队分发的早已不只是可运行镜像，还包括 charts、attestations、附属 metadata，以及越来越多被包装成 OCI 形态的 bundle。到了这个阶段，Harbor 更像一层带策略的 artifact logistics，而不再只是一个带 Web UI 的镜像架子。
Harbor 的安全姿态之所以有用，恰恰因为它没有把自己写成唯一裁判
安全层面的价值也来自这种边界感。README 说 Harbor 会对镜像做 vulnerability scanning，并支持用 policy checks 阻止存在漏洞的镜像被部署。[1] 进一步看 scanning 文档，结构就更精确了。每个 project 可以绑定自己的 scanner；若启用 “Prevent vulnerable images from running” 选项，拉取阻断会由该 project 绑定的 scanner 或全局默认 scanner 来决定。[1][9] 文档还明确指出，不同 scanners 对同一组漏洞严重级别的判断可以不同。[9]
这恰好让 Harbor 的安全表面保持了可信度。它把 scanning 和 gating 放在离 distribution 很近的位置，却没有把自己伪装成一个统一而神奇的安全结论生成器。实际运维里，这反而是更好的设计。平台团队可以把 scanning 与 policy 接到 pull path 附近，同时保留 scanner 选择、严重级别解释、例外机制，以及后续 attestation 或 admission policy 的空间。
因此，最适合 Harbor 的团队，往往并非想让注册表包办一切供应链问题的团队，而是希望注册表真正参与供应链治理的团队。Harbor 在 artifact 被 push 与 pull 的地方，提供了 projects、robot credentials、replication、caching、retention、artifact presentation，以及与 scanner 联动的 policy surface。[1][5][6][7][8][9] 它不会取代 build system、signing engine，也不会代替 cluster admission controls。它做的是把注册表变得足够聪明，让周围那些系统终于有了一个更适合连接的位置。
结尾
Harbor 在 2026 年依旧值得被当作项目导读来写，原因在于它回答了一个很多团队迟早都会重新遇到的问题：注册表什么时候不再只是被动存储，而开始成为一个内部控制点？Harbor 的回答非常具体。project 承担权限边界，robot account 承担自动化身份，replication 与 proxy cache 承担上游依赖，retention 承担生命周期策略，scanner 则把安全判断带到足够靠近 pull path 的地方，让治理真正发生。[1][5][6][7][8][9]
如果需求只有“找个地方 push 镜像”，Harbor 会显得偏重。若需求是让注册表在多类 OCI artifacts 之间承担真实的命名空间、凭证、复制与策略工作，Harbor 依旧是开源世界里最清楚的一条答案。[1][4]
来源
- GitHub，
goharbor/harborREADME 与项目主页，涵盖注册表定位、images 与 Helm charts 支持、project RBAC、replication 与 vulnerability scanning。 - GitHub API，
goharbor/harbor仓库元数据快照，包含 stars、forks、open issues、描述与文章写作时的最近 push 活动。 - GitHub 上
goharbor/harbor的 releases 页面，显示最新稳定版v2.15.0以及更新的v2.15.1-rc1预发布版本。 - CNCF 的 Harbor 项目页，提供生态定位与 graduated 项目状态。
- Harbor 文档《Create System Robot Accounts》，说明 system-wide robot accounts 作为 non-user-scoped credentials 的定位，以及跨 project 的权限表面。
- Harbor 文档《Configure Proxy Cache》，说明 proxy cache project 的行为、上游账户信任边界，以及新建 proxy cache project 默认 7 天 retention。
- Harbor 文档《Create Tag Retention Rules》，说明 project 级 retention rules、repository filters 与 artifact lifecycle 的 keep 逻辑。
- Harbor 文档《User-defined OCI artifact》，说明普通镜像之外的 OCI artifact 如何借由 Harbor-specific annotations 获得更丰富的呈现。
- Harbor 文档《Scan Individual Artifacts》及其相关 project scanner 设定，说明 scanner 选择、漏洞状态流与依赖 scanner severity 的 policy gating。
- Wikimedia Commons，文件页《File:Container-Terminal-Altenwerder-CTA-2004.jpg》，为本文所用纪实码头照片的来源页。