4. 变更门禁（Change Gate）基础

在 Kubernetes 与 IDP 自助门户的联动场景中，变更门禁（Change Gate） 是部署流水线中用于控制变更是否允许继续推进的检查点。它本质上是一个“决策关口”，只有通过门禁规则的变更才能进入下一阶段（如预发、生产）。门禁机制是保障集群稳定性、防止配置漂移和违规操作的核心防线。

4.1 变更门禁的三大类型

根据检查的执行方式和决策主体，变更门禁通常分为以下三类。在实际 IDP 门户中，这三类门禁往往组合使用，形成多层防护。

4.2 人工审批门禁

人工审批是最传统的门禁形式，通常通过工单系统、IM 机器人或 IDP 门户内置的审批面板实现。审批人根据变更内容、影响范围、历史记录等做出决策。

• 适用场景：生产环境发布、跨集群变更、涉及敏感数据的配置修改。
• 常见问题：审批疲劳、响应延迟、人为遗漏。
• 优化方向：设置审批超时自动降级、基于变更风险等级动态选择审批人、与值班表集成。

4.3 自动化检查门禁

自动化检查通过预定义的脚本、测试用例或分析工具，在变更提交后自动执行。检查结果直接决定门禁状态（通过/失败/警告）。

常见的自动化检查项包括：

1. 镜像安全扫描：检测 CVE 漏洞、恶意软件。
2. K8s 资源合规校验：使用 kubeconform 或 kubectl validate 检查 YAML 语法。
3. 单元测试与集成测试：确保业务逻辑正确。
4. 性能基线对比：对比变更前后的 P99 延迟、CPU/内存开销。
5. 依赖项检查：确认所有镜像 tag 存在、Helm chart 版本正确。

# 示例：自动化检查脚本片段（伪代码）
def check_deployment(deployment_yaml):
    errors = []
    # 1. 资源格式校验
    if not validate_yaml(deployment_yaml):
        errors.append("YAML 格式错误")
    # 2. 镜像 tag 检查
    if "latest" in extract_image_tags(deployment_yaml):
        errors.append("禁止使用 latest 标签")
    # 3. 安全上下文检查
    if not has_security_context(deployment_yaml):
        errors.append("缺少 securityContext 配置")
    return errors

4.4 策略即代码（Policy as Code）门禁

策略即代码将安全、合规、运维规则以代码形式声明，由策略引擎在变更发生时实时评估。这种方式将门禁左移，在变更进入集群前即完成拦截。

在 Kubernetes 生态中，最常用的策略引擎是 OPA（Open Policy Agent） 和 Kyverno。它们通过 Admission Webhook 机制拦截 API 请求，执行策略评估。

以下是一个 OPA 策略示例，用于强制所有 Pod 必须设置 resources.requests 和 resources.limits：

# OPA Rego 策略：强制资源限制
package kubernetes.admission

deny[msg] {
    input.request.kind.kind == "Pod"
    not input.request.object.spec.containers[_].resources.limits
    msg := "所有容器必须设置 resources.limits"
}

deny[msg] {
    input.request.kind.kind == "Pod"
    not input.request.object.spec.containers[_].resources.requests
    msg := "所有容器必须设置 resources.requests"
}

4.5 门禁流程与决策模型

下图展示了在 IDP 自助门户中，一个变更从提交到通过门禁的典型流程。三种门禁类型按阶段串联，形成完整的防护链。

4.6 门禁组合策略与最佳实践

在实际 IDP 门户中，单一门禁类型往往不足以覆盖所有风险。推荐采用“分层门禁”策略，将三种类型按阶段组合：

• 第一层（强制基线）：策略即代码——所有变更必须通过，不可跳过。
• 第二层（质量保障）：自动化检查——覆盖测试、扫描、合规校验。
• 第三层（风险决策）：人工审批——仅针对高风险变更，且设置超时自动策略。