3、准入策略核心概念：策略即代码、策略引擎与评估模型
在架构迁移过程中，传统基于人工审批或静态配置的准入控制已无法满足云原生环境对速度、一致性和可审计性的要求。策略即代码（Policy as Code, PaC） 将策略从文档和人工判断中解放出来，转化为可版本管理、自动执行、可测试的代码资产。本节围绕 PaC 的三大支柱——策略即代码、策略引擎、策略评估模型——展开，为后续的测试验证方案奠定理论基础。
3.1 策略即代码（Policy as Code）
策略即代码是指使用声明式或函数式语言将安全、合规、资源约束等准入规则编写为可执行的代码片段。这些代码与应用程序代码一样，存储在 Git 仓库中，支持 CI/CD 集成、代码审查、单元测试和版本回滚。
| 维度 | 传统策略 | 策略即代码 |
|---|---|---|
| 表达形式 | 自然语言文档、Excel 表格 | Rego、CEL、OPA 规则文件 |
| 版本管理 | 无或手动归档 | Git 分支、标签、PR 审查 |
| 执行时机 | 人工审批、事后审计 | 准入 Webhook 实时拦截 |
| 可测试性 | 低，依赖人工走查 | 高，支持单元测试与集成测试 |
| 变更影响 | 难以追溯 | 可回滚、可 diff |
关键实践： 在架构迁移中，建议将策略代码与基础设施代码（IaC）放在同一仓库，使用相同的分支策略和 CI 流水线。例如，Kubernetes 集群的准入策略（如禁止特权容器、限制 hostPath 挂载）应作为 OPA Gatekeeper 的 ConstraintTemplate 和 Constraint 资源进行版本管理。
3.2 策略引擎
策略引擎是执行策略即代码的运行时组件。它接收输入（如 Kubernetes AdmissionReview 请求、CI 构建元数据、API 调用上下文），根据加载的策略规则集进行逻辑推理，并输出评估结果。常见的策略引擎包括：
- OPA（Open Policy Agent）： 使用 Rego 语言，支持 sidecar、DaemonSet 或外部服务部署，是 Kubernetes 生态中最主流的策略引擎。
- Kyverno： 专为 Kubernetes 设计，使用 YAML 定义策略，无需学习新语言，支持 mutate、validate、generate 三种动作。
- jsPolicy： 基于 JavaScript/V8 引擎，允许使用 JavaScript 编写策略逻辑，适合前端背景的团队。
- Cloud Custodian： 面向多云环境的策略引擎，支持 AWS、Azure、GCP 资源合规检查。
选型建议： 如果团队已有 Rego 经验或需要跨平台策略（K8s + 微服务 API + Terraform），优先选择 OPA；如果团队以 Kubernetes 为中心且希望降低学习曲线，Kyverno 的 YAML 原生策略更高效。
3.3 策略评估模型：Allow / Deny / Audit / Warn
策略引擎对每个准入请求的评估结果分为四种模型，它们决定了请求的最终命运以及系统的响应行为。理解这四种模型是设计测试用例的基础。
| 评估结果 | 行为语义 | 对请求的影响 | 典型使用场景 |
|---|---|---|---|
| Allow | 请求通过所有策略检查 | 正常执行，无额外操作 | 合规资源创建、更新 |
| Deny | 请求违反至少一条强制策略 | 立即拒绝，返回错误信息 | 禁止特权容器、禁止挂载敏感目录 |
| Audit | 请求违反策略，但仅记录日志 | 请求继续执行，生成审计事件 | 灰度期策略验证、合规性基线扫描 |
| Warn | 请求违反策略，返回警告消息 | 请求继续执行，用户可见警告 | 废弃 API 版本提醒、资源标签缺失提示 |
测试陷阱： Audit 和 Warn 模式虽然不阻断请求，但大量审计日志可能淹没监控系统，且 Warn 消息在 CI 流水线中容易被忽略。测试验证方案必须包含对 Audit 日志格式、Warn 消息可读性以及日志存储压力的专项测试。
3.4 测试验证要点
基于上述核心概念，在架构迁移的准入策略测试验证方案中，需要重点关注以下测试维度：
- 策略代码正确性测试： 对每条策略编写单元测试，验证 Allow/Deny 逻辑是否符合预期。例如，测试“禁止 privileged: true”策略在输入特权容器时返回 Deny，在非特权容器时返回 Allow。
- 策略引擎集成测试： 验证引擎能否正确加载策略仓库中的最新代码，处理网络分区、Git 仓库不可用等异常场景。
- 评估模型覆盖测试： 对每种评估结果（Allow/Deny/Audit/Warn）构造至少一个正向用例和一个边界用例。特别关注 Audit 和 Warn 模式下请求是否真的被放行，以及日志/警告内容是否完整。
- 性能与压力测试： 模拟大规模并发准入请求，测量策略引擎的 P99 延迟和吞吐量，确保不成为迁移过程中的性能瓶颈。
迁移阶段建议： 在迁移初期，将新策略设置为 Audit 或 Warn 模式运行，收集基线数据并验证策略逻辑；确认无误后逐步切换为 Deny 模式。测试验证方案应覆盖这一“灰度切换”过程，确保切换前后业务不受损。