Harbor权限怎么设计？镜像仓库治理实践

Harbor不是简单的镜像存储目录，而是连接研发、CI流水线、制品安全、Kubernetes发布和审计合规的关键入口。很多企业一开始只把Harbor当作私有镜像仓库使用：所有人共用少量账号，项目随意创建，测试镜像和生产镜像混放，机器人账号长期有效。短期看推拉镜像很方便，长期看会出现权限边界不清、镜像来源不可追踪、漏洞镜像进入生产、离职人员仍能访问仓库等问题。

更稳妥的做法，是把Harbor权限设计放在镜像仓库治理框架中考虑：先划清项目边界，再定义角色和账号类型，最后把扫描、签名、保留策略、审计日志接入发布流程。与容器运行时安全、镜像扫描策略相关的内容，也可以和容器镜像安全治理一起规划。

先确定项目边界，而不是先分配账号

Harbor的项目是权限、配额、复制、扫描和保留策略的基本治理单元。如果项目边界划错，后续角色再细也很难补救。常见的错误是按个人、临时需求或流水线名称建项目，最后仓库数量激增，无法判断哪个镜像属于哪个业务、哪个环境、哪个责任团队。

企业更推荐按业务域和环境分层建模。例如，业务线可以拥有独立项目，生产和非生产镜像可以通过不同项目或命名空间隔离；平台基础镜像、公共中间件镜像、安全基线镜像应单独管理。这样做的好处是：研发团队只在自己的边界内推送镜像，平台团队可以集中治理基础镜像，安全团队可以针对关键项目设置更严格的扫描和准入规则。

一个可落地的项目划分口径通常包括三类：

• 业务应用项目：按业务线或产品线划分，承载应用镜像。
• 平台基础项目：存放基础镜像、公共运行时、Sidecar、Agent等。
• 交付隔离项目：区分开发、测试、预发、生产等环境边界。

如果企业已经有Kubernetes多集群或多命名空间治理，Harbor项目最好与集群、命名空间、团队归属保持可映射关系。这样在排查某个Pod使用了异常镜像时，可以从镜像地址快速追溯到项目、团队、流水线和发布记录。

角色设计：少用管理员，多用最小权限

Harbor内置项目管理员、开发者、访客、维护者等角色。实际治理中，最重要的原则不是把角色解释清楚，而是避免把管理员权限当作默认权限。项目管理员能够管理成员、策略和仓库配置，适合交给少数项目负责人或平台托管角色；日常研发推送镜像通常只需要开发者权限；只拉取镜像的部署系统和集群节点，不应拥有推送权限。

权限设计可以按人、系统和流程分开：

这里要特别关注机器人账号。CI系统不应使用个人账号推送镜像，因为个人离职、换岗、密码变更都会影响流水线，也会让审计链路变得混乱。推荐为每条关键流水线或每个项目创建专用机器人账号，并绑定明确的有效期、项目范围和权限范围。对于生产项目，机器人账号应只允许指定流水线推送，不允许人工复用。

将权限和镜像准入规则绑定

只做账号授权还不够。镜像仓库治理的目标不是让所有人都能顺利推送，而是确保进入仓库、进入生产的镜像可控可信。Harbor支持漏洞扫描、镜像复制、镜像保留、不可变标签等能力，这些能力应与权限一起配置。

例如，生产项目可以启用更严格的标签不可变规则，避免同一个版本号被覆盖；可以要求高危漏洞阻断发布，至少在关键业务中做到发现、评估、例外审批三步闭环；可以对基础镜像项目设置保留策略，清理过期构建产物，但保留正式发布版本和回滚版本。

一个可执行的准入思路是：

harbor_governance:
  project: payment-prod
  push_allowed: ci-robot-payment
  tag_immutable: true
  vulnerability_gate:
    block_severity: critical
    exception_required: true
  retention:
    keep_release_tags: 30
    keep_rollback_tags: 10

这类配置不一定完全通过YAML实现，但它能帮助团队把规则讲清楚：谁能推、推什么标签、哪些漏洞必须阻断、哪些镜像必须保留。对于已经建设容器平台的企业，也可以把仓库准入和Docker与容器基础规范统一到研发交付流程中。

审计与日常运营：把问题定位到责任链

Harbor权限设计完成后，仍然需要持续运营。常见巡检项包括：是否存在长期未使用账号、是否存在跨项目管理员过多、机器人账号是否过期、公开项目是否被误用、镜像标签是否被重复覆盖、漏洞扫描是否失败、镜像保留策略是否误删关键版本。

建议平台团队每月输出一次仓库治理报告，重点不是罗列所有镜像，而是识别异常模式：某个项目突然出现大量未命名标签、某条流水线推送了非预期架构镜像、某个账号在非工作时间删除镜像、某个基础镜像长期未更新。通过审计日志和CI记录关联，可以把问题定位到提交、构建、推送、部署各环节。

在组织协作上，Harbor治理应明确三类责任：平台团队负责项目和策略，业务团队负责镜像内容和版本，安全团队负责漏洞基线和例外审批。责任不清时，仓库会变成没人敢管也没人负责的公共堆场。

常见问题

1. Harbor项目应该按团队划分，还是按环境划分？

两者都可以，但要避免只按单一维度划分。按团队划分便于责任归属，按环境划分便于生产隔离。实践中可采用业务项目加环境后缀的方式，例如开发和测试项目允许更高频推送，生产项目启用不可变标签、漏洞阻断和更严格的成员管理。如果组织规模较小，也可以先按业务项目划分，再通过命名规则区分环境；当生产风险上升后，再拆出独立生产项目。

2. 是否应该给研发人员生产项目的推送权限？

通常不建议。生产镜像最好由受控CI流水线推送，研发人员通过代码合并、构建审批或发布流程间接触发。这样可以保证镜像来自可信构建环境，并且能记录提交、构建参数、依赖版本和扫描结果。若确实需要人工修复紧急问题，也应使用临时权限、限定时间窗口，并保留审批和审计记录。

3. Harbor权限治理和Kubernetes准入控制有什么关系？

Harbor负责镜像进入仓库前后的治理，Kubernetes准入控制负责镜像进入集群前的治理。两者应该衔接，而不是互相替代。比如Harbor可以阻断高危漏洞镜像推送到生产项目，Kubernetes侧可以通过准入策略限制只能拉取指定仓库、指定项目或已签名镜像。这样即使某个环节出现配置遗漏，另一个环节也能提供防线。

结语

Harbor权限设计的核心不是把账号分得更复杂，而是让镜像仓库成为可治理的交付入口。先用项目边界承载组织责任，再用最小权限控制人和系统的行为，最后用扫描、不可变标签、保留策略和审计日志形成闭环。对于正在推进容器平台化和Kubernetes生产化的团队，镜像仓库治理应与容器技术体系、发布流程和安全基线同步建设，避免在业务规模扩大后再被动补课。