Policy Check 机制原理：触发条件、检查流程与交互方式

Policy Check 是服务目录在运行时对资源变更进行合规性验证的核心机制。当用户或自动化流程尝试创建、更新或删除目录中的服务实例时，Policy Check 会在变更生效前拦截请求，将其发送至策略引擎进行决策。理解其触发条件、完整检查流程以及策略引擎与目录的交互方式，是诊断 Policy Check 失败的基础。

3.1 Policy Check 的触发条件

Policy Check 并非对所有操作都执行，而是针对特定类型的变更事件。以下表格列出了主要的触发条件及其说明：

3.2 检查流程：请求 → 策略引擎 → 决策

Policy Check 的检查流程是一个同步的、三阶段的请求-响应过程。整个流程在用户请求被持久化到数据库之前完成，确保不合规的变更不会污染服务目录的数据状态。

1. 阶段一：请求拦截与上下文构建
   • API 网关或服务目录控制器接收到用户请求。
   • 提取请求中的关键信息：操作类型（create/update/delete）、资源类型、资源 ID、请求体参数、用户身份（JWT ）、来源 IP 等。
   • 将这些信息封装为 策略评估上下文（Policy Evaluation Context），包含 subject（谁）、action（做什么）、resource（对什么资源）、environment（环境信息）。
2. 阶段二：策略引擎决策
   • 服务目录将评估上下文发送至策略引擎（如 OPA、Casbin、自定义引擎）。
   • 策略引擎加载与当前资源类型匹配的策略规则集。
   • 引擎执行规则匹配：逐条评估规则条件，如果所有条件满足，则返回该规则的决策（allow 或 deny）。
   • 如果多条规则匹配，通常遵循 deny-override 原则（任何一条规则返回 deny，则最终决策为 deny）。
   • 引擎返回决策结果，可能附带拒绝原因或建议。
3. 阶段三：决策执行与响应
   • 服务目录接收策略引擎的决策。
   • 如果决策为 allow：继续执行后续的业务逻辑（如写入数据库、触发异步任务），并向用户返回成功响应。
   • 如果决策为 deny：立即中断请求，不执行任何数据变更，并向用户返回 HTTP 403 Forbidden 或 422 Unprocessable Entity，附带策略引擎返回的拒绝原因。

3.3 策略引擎与目录的交互方式

策略引擎并非直接操作服务目录的数据库，而是通过 数据查询接口 和 事件通知机制 与目录进行松耦合交互。这种设计保证了策略引擎的无状态性和可扩展性。

3.3.1 交互模式对比

3.3.2 同步查询交互细节

在策略评估阶段，策略引擎可能需要查询服务目录以获取额外的上下文信息。例如，一条策略规则要求“只有项目管理员才能删除生产环境的服务实例”，策略引擎需要向目录查询：

• 当前用户是否属于目标项目的管理员角色？
• 目标服务实例是否部署在生产环境中？

这些查询通过服务目录暴露的 内部 API 完成，通常使用 gRPC 或 REST 接口，并设置较短的超时时间（如 500ms）以避免阻塞主流程。

3.3.3 异步推送与数据一致性

当服务目录中的资源发生变更后（例如，用户角色被更新），目录会向策略引擎发送异步事件通知。策略引擎收到通知后，会更新其内部的 策略数据缓存，确保下一次策略评估能够使用最新的数据。这种机制减少了同步查询的频率，提升了整体性能。

3.4 决策结果的结构

策略引擎返回的决策结果通常包含以下字段，这些字段对于诊断 Policy Check 失败至关重要：

{
  "decision": "deny",                // 最终决策：allow 或 deny
  "evaluation_id": "evt-20250321-001", // 本次评估的唯一 ID，用于追踪
  "matched_rules": [                  // 匹配到的规则列表
    {
      "rule_id": "rule-prod-delete-restrict",
      "rule_name": "禁止删除生产环境实例",
      "decision": "deny",
      "reason": "用户 'user-abc' 不属于项目 'proj-xyz' 的管理员角色"
    }
  ],
  "query_time_ms": 45,               // 策略引擎评估耗时
  "cache_hit": false                 // 是否命中策略引擎的本地缓存
}