📚 课程目录第3章变更门禁模型

3、变更门禁模型：门禁策略、门禁规则、门禁执行点、门禁结果反馈

在多集群自动化变更体系中，变更门禁模型是保障变更安全、合规、可追溯的核心抽象。它将人工审批、自动化检查、环境准入等分散的管控行为统一为四个正交维度：策略（Policy）、规则（Rule）、执行点（Checkpoint）、结果反馈（Feedback）。理解这四个维度的职责与协作关系，是构建可编程门禁引擎的基础。

3.1 门禁模型四要素总览

下表从职责、粒度、生命周期、典型示例四个角度对比四要素，帮助建立全局认知：

要素	职责	粒度	生命周期	典型示例
门禁策略	定义“什么条件下允许变更”的顶层约束	环境级 / 应用级	长期稳定，随环境治理基线调整	生产环境必须通过安全扫描 + 性能回归
门禁规则	实现策略的具体检查逻辑与判定标准	原子检查项	可独立增删，随工具链升级迭代	镜像漏洞数 < 5、P99 延迟增幅 < 10%
门禁执行点	在变更流水线中触发规则评估的锚点位置	流水线阶段	随 CI/CD 流程结构调整	构建后、预发部署前、灰度放量 10% 后
门禁结果反馈	将规则执行结果以结构化方式回传至决策中心	事件级	实时生成，归档至审计存储	Pass / Fail / Skip + 证据快照

设计原则：策略与规则分离，规则与执行点解耦。策略只描述“要检查什么”，规则实现“怎么检查”，执行点决定“何时检查”。三者通过结果反馈形成闭环，避免策略变更导致规则重写，或流水线调整导致检查逻辑失效。

3.2 门禁策略：顶层约束的声明式定义

门禁策略是面向运维治理的声明式契约，通常以 YAML 或 JSON 格式存储在 Git 仓库中，随环境基线版本化管理。一个策略包含：

目标选择器：匹配集群、命名空间、应用标签。
规则引用列表：按优先级排序的规则 ID 集合。
执行模式：阻塞（Blocking）或告警（Warning）。
生效时段：变更窗口、静默期等时间约束。

# 生产环境门禁策略示例
apiVersion: gatekeeper.ops.io/v1
kind: ChangePolicy
metadata:
  name: prod-strict-gate
spec:
  selector:
    clusters: ["prod-*"]
    namespaces: ["default", "critical"]
  rules:
    - ruleID: "image-vuln-scan"       # 镜像漏洞扫描
      priority: 1
    - ruleID: "performance-regression" # 性能回归检查
      priority: 2
    - ruleID: "config-drift-detect"    # 配置漂移检测
      priority: 3
  mode: Blocking
  window:
    start: "09:00"
    end: "18:00"
    timezone: "Asia/Shanghai"

3.3 门禁规则：原子检查逻辑的插件化实现

门禁规则是门禁引擎的可插拔执行单元。每条规则独立封装，包含：

输入：变更元数据（镜像 Tag、配置 diff、流量指标）。
判定逻辑：调用外部 API（漏洞库、监控系统）或本地计算。
输出：Pass / Fail / Error + 结构化证据。
超时与重试：防止外部依赖阻塞流水线。

规则注册示例（Go 伪代码）：

// 镜像漏洞扫描规则
type ImageVulnRule struct{}

func (r *ImageVulnRule) ID() string { return "image-vuln-scan" }

func (r *ImageVulnRule) Evaluate(ctx *RuleContext) (*Result, error) {
    report, err := ctx.TrivyClient.Scan(ctx.ImageRef)
    if err != nil {
        return &Result{Status: Error, Message: err.Error()}, nil
    }
    if report.CriticalCount > 0 || report.HighCount > 5 {
        return &Result{
            Status:  Fail,
            Message: fmt.Sprintf("Critical: %d, High: %d", report.CriticalCount, report.HighCount),
            Evidence: report,
        }, nil
    }
    return &Result{Status: Pass, Evidence: report}, nil
}

3.4 门禁执行点：流水线中的锚点编排

执行点将策略与规则绑定到具体的流水线阶段。常见的执行点包括：

执行点名称	触发时机	典型检查内容	阻塞级别
pre-commit	代码提交前	配置文件格式、密钥泄露扫描	低
post-build	镜像构建完成后	镜像漏洞、基础镜像合规	中
pre-deploy	部署到目标集群前	资源配额、网络策略、RBAC 权限	高
post-deploy-canary	灰度部署后、全量前	错误率、延迟、日志异常	高
post-deploy-full	全量部署完成后	配置漂移、健康检查	低（仅告警）

执行点通过门禁上下文传递变更快照，确保规则在正确的数据范围内执行：

// 门禁上下文结构
type CheckpointContext struct {
    CheckpointID string      // 执行点唯一标识
    ChangeID     string      // 变更单 ID
    Cluster      string      // 目标集群
    Artifacts    []Artifact  // 变更制品列表
    Metrics      *MetricsSnapshot // 当前集群指标快照
    Timestamp    time.Time
}

3.5 门禁结果反馈：闭环决策与审计

结果反馈是门禁模型的神经末梢，负责将规则执行结果实时回传至门禁引擎，触发以下动作：

决策聚合：汇总同一执行点下所有规则的结果，按策略模式（Blocking / Warning）生成最终门禁状态。
变更阻断：若为 Blocking 模式且任一规则 Fail，立即中止流水线并回滚。
审计归档：将结果快照写入不可篡改的审计存储（如对象存储 + 区块链哈希）。
通知分发：通过 Webhook 将结果推送至变更平台、IM 群、监控告警系统。

常见陷阱：结果反馈仅传递“通过/失败”二元状态，忽略证据快照。这会导致事后审计时无法复现检查上下文。务必在反馈中携带规则版本、输入参数、原始响应等结构化证据，确保可追溯性。

3.6 门禁模型协作流程（SVG）

下图展示一次多集群变更中，策略、规则、执行点、结果反馈四要素的完整协作流程：

3.7 多集群场景下的门禁模型扩展

当门禁模型应用于多集群环境时，需要额外关注以下扩展点：

策略继承与覆盖：全局基线策略可被集群级策略覆盖，集群级策略可被命名空间级策略覆盖。
规则分布式执行：规则可在中心引擎执行（集中式），也可下推到集群侧执行（边缘式），结果统一汇聚。
执行点差异化：不同集群的流水线阶段可能不同，执行点需支持按集群标签动态绑定。
结果反馈去重与排序：多集群并行变更时，结果反馈需携带全局序列号，避免乱序导致决策错误。

多集群策略继承示例：

# 全局基线策略
apiVersion: gatekeeper.ops.io/v1
kind: ChangePolicy
metadata:
  name: global-baseline
spec:
  rules: ["image-vuln-scan", "config-drift-detect"]
  mode: Warning

# 生产集群覆盖策略（继承全局 + 追加规则）
apiVersion: gatekeeper.ops.io/v1
kind: ChangePolicy
metadata:
  name: prod-override
  annotations:
    parent-policy: "global-baseline"
spec:
  selector:
    clusters: ["prod-*"]
  rules:
    - ruleID: "performance-regression"
      priority: 1
    - ruleID: "rbac-audit"
      priority: 2
  mode: Blocking

通过上述模型，变更门禁从“人工审批 + 简单检查”升级为可编程、可观测、可审计的自动化决策系统，为多集群变更提供一致的安全护栏。