---
url: /sre/devops/cicd/harbor-source-control.md
description: 在现代企业 IT 架构中，研发与运维的协作边界往往在制品库相遇。
---

![CI 制品源管控与「软着陆」治理实践](https://media.xiaolin.fun/docs/img-harbor-source-control/infographic-01.png)

在现代企业 IT 架构中，研发与运维的协作边界往往在制品库相遇。研发团队主导持续集成（CI），负责将代码构建为镜像并推送到镜像仓库；运维团队主导持续部署（CD），负责从镜像仓库拉取镜像并部署到各环境。

作为两者的「临界区」，以 Harbor 为代表的镜像仓库，其安全与规范直接决定了整个交付链条的稳定性。然而，在实际运行中，由于历史遗留、团队习惯或系统碎片化，镜像仓库往往面临「多源推送」的混乱局面。

本文将探讨在多源推送（存在 A、B、C、D 四个源，其中 A 为官方推荐的唯一受信源）的背景下，如何通过「技术手段 + 管理手段」实现非受信源（B、C、D）的「软着陆」收拢治理，并在保障业务连续性的前提下，最终达成仅允许 A 源推送的管控目标。

## 混乱的多源推送现状

![多源推送的质量后门与发布痛点](https://media.xiaolin.fun/docs/img-harbor-source-control/infographic-02.png)

在许多企业的发展初期，为了追求敏捷开发和快速迭代，通常采用最小可行性产品（MVP）的模式交付。在这种“唯快不破”的氛围下，开发团队为了方便，会寻找各种便捷的构建路径；而运维团队在早期阶段也往往只关心“部署是否成功”，对“镜像是从哪里推送过来的”并不敏感。这种协作默契，直接催生了 Harbor 仓库中并存的多种推送源：

* **源 A（受信任的唯一目标源）**：统一开发管理平台的 CI Server（类似于 GitHub Runner），作为官方推荐的唯一受信构建节�在治理逻辑上，我们将 A、B、C、D 四个制品推送源的推送凭证形象地比喻为「四把钥匙」。治理的终极目标是收回 B、C、D 这三把不安全、不合规的「钥匙」，最终实现仅保留 A 钥匙的统一管控。方案一的核心实施步骤如下：

1. **技术手段：日志审计与钥匙追踪（基线审计）**
   * **操作方式**：运维团队通过分析 Harbor 的审计日志进行源头追踪。
   * **实现目标**：利用技术日志，精准识别出「哪个开发团队在什么时间、从哪个 IP 节点使用了哪把不合规的钥匙（B、C、D）」，输出明确的未整改清单。

2. **管理手段：周报通报与行政督导（管理施压）**
   * **操作方式**：运维侧指派专职接口人，每周对日志审计数据进行汇总，生成「未交钥匙团队通报看板」。
   * **实现目标**：每周向 IT 管理层和研发负责人发送通报邮件。通过高层关注与跨部门协同，形成有效的整改压力，促使各团队将迁移排期落地。

3. **「钥匙」主动上交与注销（整改闭环）**
   * **操作方式**：运维配合研发团队，提供标准的官方 CI 配置文件模板，实现无感迁移。迁移完成后，主动注销并上交 B、C、D 的推送凭证（如注销自建 Jenkins 机器人账户、关闭 PaaS 控制台手动上传入口）。
   * **整改标志**：以系统日志中该渠道推送记录彻底归零、且对应推送凭证已注销为整改完成的终点。

**多维评估**：

* 💰 **经济成本**：**极低**。运维仅需编写日志分析脚本，无需开发复杂的拦截卡口或动态标记系统；研发迁移工作逐步排期，开发成本平稳。
* ⏳ **时间成本**：**极高且难以预估**。由于整改进度管控在交钥匙前处于「0 或 1」的黑盒状态，时间进度上很容易拖延。
* 🎯 **目标成效**：**低（偏理想化，实际落地效果较差）**。��发侧绕过规则提供了一个“质量滑坡”的后门\*\*。

现在，运维团队为了提高版本质量，终于开始对 CI 侧的质量进行管控，要求所有镜像必须从源 A 推送，不能从其他渠道推送。最直接的好处是，实现了 CI 统一管理，便于增加各类质量门禁，从技术上落实更严格的管控。另外一方面，打造统一能力，节省运维成本。

## 治理原则：「软着陆」而非「一刀切」

面对上述隐患，最简单的做法是「一刀切」：直接在 Harbor 上回收 B、C、D 的推送权限。但在实际企业环境中，这种做法往往会带来灾难：

* **业务中断风险**：强行关闭可能导致部分核心业务的紧急修复（Hotfix）无法上线，引发故障。
* **研发运维对立**：强硬的管控会招致开发团队的强烈抵触，导致治理流产。

因此，制品源管控的核心原则是**软着陆**。通过**技术防线 + 管理缓冲区**的双轨制，给开发团队留出合理的整改与过渡时间，通过「小步快跑」的阶段性演进，平滑地将所有推送源收拢至 A。

## 治理方案与多维评估

在中大型企业中，任何技术治理方案的落地，都不能仅凭技术人员的一意孤行。我们需要从**经济成本**（开发与运维的工时投入）、**时间成本**（从启动到完全收拢的周期）以及**目标成效**（安全性与业务连续性）三个维度进行综合评估。

针对制品源管控的诉求，运维团队初步评估了以下两个治理方案：

***

### 方案一：行政督导与凭证收拢（渐进式管理推动）

![行政督导与自证成本极高](https://media.xiaolin.fun/docs/img-harbor-source-control/infographic-03.png)

该方案主要是**管理手段**，即通过行政施压与排期闭环来强力推动整改，而技术手段仅作为辅助。

在治理逻辑上，我们将 A、B、C、D 四个制品推送源的推送凭证形象地比喻为“四把钥匙”。治理的终极目标是收回 B、C、D 这三把不安全、不合规的“钥匙”，最终实现仅保留 A 钥匙的统一管控。方案一的核心实施步骤如下：

1. **技术手段：日志审计与钥匙追踪（基线审计）**
   * **操作方式**：运维团队通过分析 Harbor 的审计日志进行源头追踪。
   * **实现目标**：利用技术日志，精准识别出“哪个开发团队在什么时间、从哪个 IP 节点使用了哪把不合规的钥匙（B、C、D）”，输出明确的未整改清单。

2. **管理手段：周报通报与行政督导（管理施压）**
   * **操作方式**：运维侧指派专职接口人，每周对日志审计数据进行汇总，生成“未交钥匙团队通报看板”。
   * **实现目标**：每周向 IT 管理层和研发负责人发送通报邮件。通过高层关注与跨部门协同，形成有效的整改压力，促使各团队将迁移排期落地。

3. **“钥匙”主动上交与注销（整改闭环）**
   * **操作方式**：运维配合研发团队，提供标准的官方 CI 配置文件模板，实现无感迁移。迁移完成后，主动注销并上交 B、C、D 的推送凭证（如注销自建 Jenkins 机器人账户、关闭 PaaS 控制台手动上传入口）。
   * **整改标志**：以系统日志中该渠道推送记录彻底归零、且对应推送凭证已注销为整改完成的终点。

**多维评估**：

* 💰 **经济成本**：**极低**。运维仅需编写日志分析脚本，无需开发复杂的拦截卡口或动态标记系统；研发迁移工作逐步排期，开发成本平稳。
* ⏳ **时间成本**：**极高且难以预估**。由于整改进度管控在交钥匙前处于“0 或 1”的黑盒状态，时间进度上很容易拖延。
* 🎯 **目标成效**：**低（偏理想化，实际落地效果较差）**。

在实际落地中，该方案存在以下致命痛点：

1. **日志审计实现粗糙**：在中大型企业错综复杂的系统环境下，仅靠简单的日志分析脚本去精确审计多个团队的系统日志，实现起来非常复杂，效果往往十分粗糙。
2. **通报粒度粗，自证成本高**：由于日志分析的局限性，周报通报的内容粒度很粗，数据可信度极易受到开发团队的质疑。运维侧需要承担极高的“自证成本”去证明违规推送的具体源头，容易陷入繁琐的自证泥潭。
3. **进度黑盒，管理困难**：因为没有技术卡口阻断，整改进度是完全无法预估的黑盒，这导致管理推进极其吃力，在现实生产条件下很难达成最终的收拢目标。

***

### 方案二：基于构建凭证的防伪与扫描校验（技术硬性管控）

该方案更侧重于**技术硬卡口手段**，通过在镜像构建期注入不可伪造的“防伪凭证”，在仓库端或准入端进行自动扫描解析，从根本上解决“镜像来源不可信”的问题。

#### 1. 核心技术设计

在容器镜像的技术规范中，Harbor 中的容器镜像本身默认不包含构建“来源”的元数据，在仓库中它们是无差别的。同时，根据\*\*不可变基础设施（Immutable Infrastructure）\*\*的设计原则，我们不能在镜像打包完成推送后再通过外部手段强行打标或修改，因为这会改变镜像的 Hash 校验和，破坏其不可变特性。

因此，该方案将关注点前移至 **Dockerfile 构建期**，通过建立签名防伪机制，打通以下互信链条：

```text
[源 A CI 平台 (拥有私钥)] 
    ──(构建时自动注入密文凭证) 
        ──> [Container Image (不可变)] 
            ──(推送)──> [Harbor 扫描/准入端解析 (公钥校验)]
```

* **构建期注入**：在源 A 的 CI Server 进行镜像构建时，由 Runner 在 Dockerfile 编译步骤中，自动向镜像内的特定路径（或通过镜像 `LABEL` 字段）注入一段「不可伪造」的加密凭证文件。开发团队自己没有也不应该拥有这个凭证，其管理由官方 CI 平台责任人掌控。
* **互信链建立**：该凭证的私钥仅归属于源 A 平台，公钥归属于运维团队。CI 源 A 和运维团队实现互信，开发团队由于拿不到凭证私钥，无法在本地（源 D）或自建 Jenkins（源 B）中伪造该凭证。
* **扫描与解析**：镜像推送到 Harbor 后，Harbor 自动触发镜像内容扫描，或者在 CD 准入阶段（如 Kubernetes Admission Webhook）进行解析。只要能通过公钥正确解密并验证该凭证，即确信该镜像 100% 来源于官方受信源 A；否则判定为「其他」非受信源推送。

```dockerfile
FROM alpine:3.18

# 1. 声明由官方 CI 传入的凭证构建参数
ARG CI_SIGNATURE_TOKEN

# 2. 将凭证写入不可变容器的文件系统中，用于后续镜像内容审计与准入校验
RUN mkdir -p /etc/image-metadata && \
    echo "${CI_SIGNATURE_TOKEN}" > /etc/image-metadata/signature.key

# 3. 亦可通过 LABEL 元数据进行暴露，便于容器仓库或 admission webhook 在外部解析
LABEL cn.xiaolinstar.image.source="CI-A" \
      cn.xiaolinstar.image.signature="${CI_SIGNATURE_TOKEN}"
```

![基于构建凭证的防伪与量化白盒审计](https://media.xiaolin.fun/docs/img-harbor-source-control/infographic-04.png)

#### 2. 量化目标与成效

通过该技术手段，运维可以实现极细粒度的数字管控，彻底消除“整改进度黑盒”的尴尬。
例如，运维大盘可以实时展示监控指标：`90 / 101`（表示当前用于部署的 101 个镜像中，有 90 个能成功解析凭证并确信来自官方源 A，其余 11 个为违规待整改镜像）。

**多维评估**：

* 💰 **经济成本**：**中等**。运维团队需要开发凭证注入与解析校验逻辑（如准入控制器），这需要一定的工时投入；但后续的“自证成本”和口头沟通成本降为 `0`。
* ⏳ **时间成本**：**中等**（约 `1 ~ 2` 个月）。由于整改进度完全白盒化，整改数据可精确到个位数，时间更容易评估。
* 🎯 **目标成效**：**极高**。由于凭证不可伪造，彻底堵死了开发通过自建管道或本地推送绕过安全基线的后门。运维侧无自证压力，数据完全真实可信。

### 方案对比总结

| 评估维度 | 方案一：行政督导与凭证收拢（管理为主） | 方案二：构建凭证防伪校验（技术为主） |
| :--- | :--- | :--- |
| **技术实现** | 简单的 Harbor 审计日志过滤，无法防伪且效果粗糙 | Dockerfile 构建期凭证自动注入，公钥校验防伪 |
| **自证成本** | 极高（通报数据常被开发质疑，运维需人工核对） | 0（系统自动校验解析，数据 100% 真实可信） |
| **进度可视度** | `0-1` 黑盒状态（交钥匙前无法评估中间整改率） | 精细化白盒状态（例如实时展现 `90 / 101` 的整改比例） |
| **业务连续性** | 极高（不设强拦截，对开发完全无感） | 中等（在 CD 准入端强校验会导致未整改业务中断） |
| **最终成效** | 较差（偏理想化，自证成本高，整改易流于形式） | 极佳（从源头上杜绝了质量滑坡的后门） |

## 工作思考：让技术为管理服务

![让技术为管理服务，达成治理最优闭环](https://media.xiaolin.fun/docs/img-harbor-source-control/infographic-05.png)

作为一个游走在研发与运维交界处的 SRE，我深切感受到程序员在 CI/CD 中所蕴含的那些设计思想，其影响早已超越了技术本身，甚至直击企业运营管理的本质。

我们熟知的 Git 版本管理、摘要指纹、不可篡改性以及签名防伪校验等机制，其底层哲学极其纯粹。而在企业管理视角下，这些技术属性实际上在润物无声地解决着运营管理中最令人头疼的**推诿扯皮与职责不清**问题。

把「管理问题技术化，技术手段确定化」，当系统能自动审计出 `90 / 101` 这种无可争议的量化白盒数据时，职责边界立现，扯皮自然烟消云散。这才是技术人在企业治理中能贡献的最高价值。