在现代企业 IT 架构中，研发与运维的协作边界往往在制品库相遇。研发团队主导持续集成（CI），负责将代码构建为镜像并推送到镜像仓库；运维团队主导持续部署（CD），负责从镜像仓库拉取镜像并部署到各环境。
作为两者的「临界区」，以 Harbor 为代表的镜像仓库，其安全与规范直接决定了整个交付链条的稳定性。然而，在实际运行中，由于历史遗留、团队习惯或系统碎片化，镜像仓库往往面临「多源推送」的混乱局面。
本文将探讨在多源推送（存在 A、B、C、D 四个源，其中 A 为官方推荐的唯一受信源）的背景下，如何通过「技术手段 + 管理手段」实现非受信源（B、C、D）的「软着陆」收拢治理，并在保障业务连续性的前提下，最终达成仅允许 A 源推送的管控目标。
混乱的多源推送现状
在许多企业的发展初期，为了追求敏捷开发和快速迭代，通常采用最小可行性产品（MVP）的模式交付。在这种“唯快不破”的氛围下，开发团队为了方便，会寻找各种便捷的构建路径；而运维团队在早期阶段也往往只关心“部署是否成功”，对“镜像是从哪里推送过来的”并不敏感。这种协作默契，直接催生了 Harbor 仓库中并存的多种推送源：
- 源 A（受信任的唯一目标源）：统一开发管理平台的 CI Server（类似于 GitHub Runner），作为官方推荐的唯一受信构建节�在治理逻辑上，我们将 A、B、C、D 四个制品推送源的推送凭证形象地比喻为「四把钥匙」。治理的终极目标是收回 B、C、D 这三把不安全、不合规的「钥匙」，最终实现仅保留 A 钥匙的统一管控。方案一的核心实施步骤如下：
技术手段：日志审计与钥匙追踪（基线审计）
- 操作方式：运维团队通过分析 Harbor 的审计日志进行源头追踪。
- 实现目标：利用技术日志，精准识别出「哪个开发团队在什么时间、从哪个 IP 节点使用了哪把不合规的钥匙（B、C、D）」，输出明确的未整改清单。
管理手段：周报通报与行政督导（管理施压）
- 操作方式：运维侧指派专职接口人，每周对日志审计数据进行汇总，生成「未交钥匙团队通报看板」。
- 实现目标：每周向 IT 管理层和研发负责人发送通报邮件。通过高层关注与跨部门协同，形成有效的整改压力，促使各团队将迁移排期落地。
「钥匙」主动上交与注销（整改闭环）
- 操作方式：运维配合研发团队，提供标准的官方 CI 配置文件模板，实现无感迁移。迁移完成后，主动注销并上交 B、C、D 的推送凭证（如注销自建 Jenkins 机器人账户、关闭 PaaS 控制台手动上传入口）。
- 整改标志：以系统日志中该渠道推送记录彻底归零、且对应推送凭证已注销为整改完成的终点。
多维评估：
- 💰 经济成本：极低。运维仅需编写日志分析脚本，无需开发复杂的拦截卡口或动态标记系统；研发迁移工作逐步排期，开发成本平稳。
- ⏳ 时间成本：极高且难以预估。由于整改进度管控在交钥匙前处于「0 或 1」的黑盒状态，时间进度上很容易拖延。
- 🎯 目标成效：低（偏理想化，实际落地效果较差）。��发侧绕过规则提供了一个“质量滑坡”的后门**。
现在，运维团队为了提高版本质量，终于开始对 CI 侧的质量进行管控，要求所有镜像必须从源 A 推送，不能从其他渠道推送。最直接的好处是，实现了 CI 统一管理，便于增加各类质量门禁，从技术上落实更严格的管控。另外一方面，打造统一能力，节省运维成本。
治理原则：「软着陆」而非「一刀切」
面对上述隐患，最简单的做法是「一刀切」：直接在 Harbor 上回收 B、C、D 的推送权限。但在实际企业环境中，这种做法往往会带来灾难：
- 业务中断风险：强行关闭可能导致部分核心业务的紧急修复（Hotfix）无法，引发故障。
- 研发运维对立：强硬的管控会招致开发团队的强烈抵触，导致治理流产。
因此，制品源管控的核心原则是软着陆。通过技术防线 + 管理缓冲区的双轨制，给开发团队留出合理的整改与过渡时间，通过「小步快跑」的阶段性演进，平滑地将所有推送源收拢至 A。
治理方案与多维评估
在中大型企业中，任何技术治理方案的落地，都不能仅凭技术人员的一意孤行。我们需要从经济成本（开发与运维的工时投入）、时间成本（从启动到完全收拢的周期）以及目标成效（安全性与业务连续性）三个维度进行综合评估。
针对制品源管控的诉求，运维团队初步评估了以下两个治理方案：
方案一：行政督导与凭证收拢（渐进式管理推动）
该方案主要是管理手段，即通过行政施压与排期闭环来强力推动整改，而技术手段仅作为辅助。
在治理逻辑上，我们将 A、B、C、D 四个制品推送源的推送凭证形象地比喻为“四把钥匙”。治理的终极目标是收回 B、C、D 这三把不安全、不合规的“钥匙”，最终实现仅保留 A 钥匙的统一管控。方案一的核心实施步骤如下：
技术手段：日志审计与钥匙追踪（基线审计）
- 操作方式：运维团队通过分析 Harbor 的审计日志进行源头追踪。
- 实现目标：利用技术日志，精准识别出“哪个开发团队在什么时间、从哪个 IP 节点使用了哪把不合规的钥匙（B、C、D）”，输出明确的未整改清单。
管理手段：周报通报与行政督导（管理施压）
- 操作方式：运维侧指派专职接口人，每周对日志审计数据进行汇总，生成“未交钥匙团队通报看板”。
- 实现目标：每周向 IT 管理层和研发负责人发送通报邮件。通过高层关注与跨部门协同，形成有效的整改压力，促使各团队将迁移排期落地。
“钥匙”主动上交与注销（整改闭环）
- 操作方式：运维配合研发团队，提供标准的官方 CI 配置文件模板，实现无感迁移。迁移完成后，主动注销并上交 B、C、D 的推送凭证（如注销自建 Jenkins 机器人账户、关闭 PaaS 控制台手动上传入口）。
- 整改标志：以系统日志中该渠道推送记录彻底归零、且对应推送凭证已注销为整改完成的终点。
多维评估：
- 💰 经济成本：极低。运维仅需编写日志分析脚本，无需开发复杂的拦截卡口或动态标记系统；研发迁移工作逐步排期，开发成本平稳。
- ⏳ 时间成本：极高且难以预估。由于整改进度管控在交钥匙前处于“0 或 1”的黑盒状态，时间进度上很容易拖延。
- 🎯 目标成效：低（偏理想化，实际落地效果较差）。
在实际落地中，该方案存在以下致命痛点：
- 日志审计实现粗糙：在中大型企业错综复杂的系统环境下，仅靠简单的日志分析脚本去精确审计多个团队的系统日志，实现起来非常复杂，效果往往十分粗糙。
- 通报粒度粗，自证成本高：由于日志分析的局限性，周报通报的内容粒度很粗，数据可信度极易受到开发团队的质疑。运维侧需要承担极高的“自证成本”去证明违规推送的具体源头，容易陷入繁琐的自证泥潭。
- 进度黑盒，管理困难：因为没有技术卡口阻断，整改进度是完全无法预估的黑盒，这导致管理推进极其吃力，在现实生产条件下很难达成最终的收拢目标。
方案二：基于构建凭证的防伪与扫描校验（技术硬性管控）
该方案更侧重于技术硬卡口手段，通过在镜像构建期注入不可伪造的“防伪凭证”，在仓库端或准入端进行自动扫描解析，从根本上解决“镜像来源不可信”的问题。
1. 核心技术设计
在容器镜像的技术规范中，Harbor 中的容器镜像本身默认不包含构建“来源”的元数据，在仓库中它们是无差别的。同时，根据**不可变基础设施（Immutable Infrastructure）**的设计原则，我们不能在镜像打包完成推送后再通过外部手段强行打标或修改，因为这会改变镜像的 Hash 校验和，破坏其不可变特性。
因此，该方案将关注点前移至 Dockerfile 构建期，通过建立签名防伪机制，打通以下互信链条：
[源 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；否则判定为「其他」非受信源推送。
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}"
2. 量化目标与成效
通过该技术手段，运维可以实现极细粒度的数字管控，彻底消除“整改进度黑盒”的尴尬。 例如，运维大盘可以实时展示监控指标：90 / 101（表示当前用于部署的 101 个镜像中，有 90 个能成功解析凭证并确信来自官方源 A，其余 11 个为违规待整改镜像）。
多维评估：
- 💰 经济成本：中等。运维团队需要开发凭证注入与解析校验逻辑（如准入控制器），这需要一定的工时投入；但后续的“自证成本”和口头沟通成本降为
0。 - ⏳ 时间成本：中等（约
1 ~ 2个月）。由于整改进度完全白盒化，整改数据可精确到个位数，时间更容易评估。 - 🎯 目标成效：极高。由于凭证不可伪造，彻底堵死了开发通过自建管道或本地推送绕过安全基线的后门。运维侧无自证压力，数据完全真实可信。
方案对比总结
| 评估维度 | 方案一：行政督导与凭证收拢（管理为主） | 方案二：构建凭证防伪校验（技术为主） |
|---|---|---|
| 技术实现 | 简单的 Harbor 审计日志过滤，无法防伪且效果粗糙 | Dockerfile 构建期凭证自动注入，公钥校验防伪 |
| 自证成本 | 极高（通报数据常被开发质疑，运维需人工核对） | 0（系统自动校验解析，数据 100% 真实可信） |
| 进度可视度 | 0-1 黑盒状态（交钥匙前无法评估中间整改率） | 精细化白盒状态（例如实时展现 90 / 101 的整改比例） |
| 业务连续性 | 极高（不设强拦截，对开发完全无感） | 中等（在 CD 准入端强校验会导致未整改业务中断） |
| 最终成效 | 较差（偏理想化，自证成本高，整改易流于形式） | 极佳（从源头上杜绝了质量滑坡的后门） |
工作思考：让技术为管理服务
作为一个游走在研发与运维交界处的 SRE，我深切感受到程序员在 CI/CD 中所蕴含的那些设计思想，其影响早已超越了技术本身，甚至直击企业运营管理的本质。
我们熟知的 Git 、摘要指纹、不可篡改性以及签名防伪校验等机制，其底层哲学极其纯粹。而在企业管理视角下，这些技术属性实际上在润物无声地解决着运营管理中最令人头疼的推诿扯皮与职责不清问题。
把「管理问题技术化，技术手段确定化」，当系统能自动审计出 90 / 101 这种无可争议的量化白盒数据时，职责边界立现，扯皮自然烟消云散。这才是技术人在企业治理中能贡献的最高价值。