4. 质量门禁概念：定义、位置与策略类型
质量门禁（Quality Gate）是制品交付流水线中一道可编程的“质量闸门”。它不是一个静态检查点，而是一组通过/阻断规则的集合：只有当制品（如容器镜像）同时满足所有预设指标阈值时，门禁才会放行，允许制品进入下一阶段（如预发环境或生产仓库）；否则流水线被阻断，并触发告警或回退流程。
核心思想：质量门禁将“事后检测”转变为“事前阻断”。在 Harbor 场景中，镜像拉取延迟、漏洞数量、签名状态、合规标签等均可作为门禁判定因子。
4.1 质量门禁在制品交付中的位置
在典型的容器化交付流水线中，质量门禁通常位于制品构建完成之后、部署到目标环境之前的衔接点。它充当了开发与运维之间的契约边界，确保只有通过质量审计的镜像才能进入生产级制品库。
位置要点：门禁不应放在构建阶段内部（会拖慢开发迭代），也不应放在生产环境之后（失去防护意义）。最佳位置是制品推送至 Harbor 仓库后、标记为“可部署”之前。
4.2 质量门禁策略类型
根据判定维度和触发时机，Harbor 场景下的质量门禁策略可分为以下四大类：
| 策略类型 | 判定依据 | 典型阈值示例 | 阻断行为 |
|---|---|---|---|
| 安全漏洞门禁 | Trivy / Clair 扫描结果 | Critical ≥ 1 或 High ≥ 5 则阻断 | 禁止镜像推送至生产仓库 |
| 性能延迟门禁 | 镜像拉取延迟 P99 指标 | P99 拉取延迟 > 8s 则告警阻断 | 触发镜像预热或回退至上一版本 |
| 签名与合规门禁 | Cosign / Notary 签名验证 | 镜像必须携带有效数字签名 | 拒绝未签名镜像进入运行环境 |
| 制品元数据门禁 | 标签规范 / SBOM 完整性 | 缺少 sbom.json 或标签格式不符 | 阻断并通知开发者补充元数据 |
4.3 门禁策略的组合执行模型
在实际生产环境中，单一维度的门禁往往不够。推荐采用分层门禁模型：将策略按严重程度分为阻断级（Blocking）和告警级（Warning），并支持按环境差异化配置。
4.4 门禁策略配置示例（Harbor Webhook + OPA）
在 Harbor 中，质量门禁通常通过 Webhook + 外部策略引擎（如 OPA / Gatekeeper） 实现。以下是一个基于 OPA Rego 策略的阻断门禁示例：
package harbor.qualitygate
# 阻断规则：禁止任何包含 Critical 漏洞的镜像进入生产仓库
default allow = false
allow {
input.repository == "prod/*"
not has_critical_vuln
}
has_critical_vuln {
some vuln in input.scan_results.vulnerabilities
vuln.severity == "CRITICAL"
}
# 告警规则：拉取延迟超过 8s 时记录告警但不阻断
warn_high_latency {
input.pull_latency_p99 > 8
}
实践注意：门禁策略应版本化管理（GitOps），每次变更需经过 Code Review。避免在门禁规则中硬编码环境名称或 IP 地址，应使用标签选择器实现环境差异化。
4.5 门禁策略的度量与迭代
质量门禁不是一次性配置，需要持续度量其有效性。建议跟踪以下指标：
- 门禁阻断率：被阻断的推送次数 / 总推送次数。过高说明开发质量差，过低说明门禁过于宽松。
- 门禁误报率：人工审核后判定为误阻断的次数 / 总阻断次数。目标 < 5%。
- 门禁平均判定耗时：从镜像推送完成到门禁输出结果的时间。应 < 30s，避免阻塞流水线。
- 门禁覆盖度：已配置门禁的仓库数 / 总活跃仓库数。目标 100%。
通过定期复盘这些指标，团队可以动态调整门禁阈值，在质量保障与交付效率之间找到最佳平衡点。