4. 多环境策略管理：开发、测试、预发布、生产环境的策略差异化设计
在真实交付流水线中，同一份 Policy-as-Code 规则集无法在所有环境中原样生效。开发环境需要宽松以加速迭代，生产环境必须严格以保障合规。本章聚焦如何为开发、测试、预发布、生产四个典型环境设计差异化的策略模板，并通过 Runbook 联动实现策略的自动晋升与回退。
4.1 环境策略差异化原则
策略差异化不是简单复制规则后修改参数，而是基于环境信任等级与风险容忍度进行分层设计。核心原则包括：
- 基线统一：所有环境共享同一套策略 Schema 与规则 ID，避免规则碎片化。
- 参数化阈值：通过环境变量或配置映射调整规则参数（如允许的开放端口范围、镜像拉取频率上限）。
- 环境标签驱动：使用
environment: dev|test|staging|prod标签决定策略生效范围。 - 强制晋升门禁：低环境策略必须通过验证才能晋升到高环境，禁止跳过。
关键指标：生产环境策略拒绝率通常为开发环境的 3-5 倍，但误报率应控制在 2% 以下，否则会阻塞发布。
4.2 四环境策略差异化对照表
下表从策略维度、规则示例、执行模式、违规处理四个角度对比四个环境的策略设计差异：
| 策略维度 | 开发 (Dev) | 测试 (Test) | 预发布 (Staging) | 生产 (Prod) |
|---|---|---|---|---|
| 容器安全基线 | 仅阻止高危 CVE（CVSS ≥ 9.0） | 阻止高危 + 中危（CVSS ≥ 7.0） | 阻止高危 + 中危 + 部分低危 | 阻止所有已知 CVE，强制签名验证 |
| 网络策略 | 允许所有出口，仅限制入站 | 允许白名单出口，限制入站 | 最小权限出口，严格入站 ACL | 零信任网络，所有流量需显式授权 |
| 资源配额 | 宽松（CPU 无限制，内存 8Gi 上限） | 中等（CPU 4 核，内存 4Gi） | 接近生产（CPU 2 核，内存 2Gi） | 严格（CPU 1 核，内存 1Gi，HPA 绑定） |
| 合规审计 | 仅记录日志，不阻断 | 记录日志 + 告警 | 记录日志 + 告警 + 自动阻断 | 全量审计 + 阻断 + 自动生成工单 |
| 策略执行模式 | Audit（仅审计） | Audit + Warn | Warn + 部分 Enforce | Enforce（强制阻断） |
| 违规处理 | 记录到开发者控制台 | 发送通知到测试群 | 触发 Runbook 自动修复 | 触发 P0 告警 + 自动回滚 |
实践建议：在开发环境使用
audit 模式收集策略违规数据，用于优化规则阈值；生产环境必须使用 enforce 模式，且所有策略变更需经过预发布环境验证。
4.3 策略晋升流程与 Runbook 联动
策略从开发环境晋升到生产环境需要经过严格的验证管道。下图展示了策略晋升的四个阶段以及每个阶段触发的 Runbook 动作：
4.4 策略差异化配置示例
以下是一个基于 OPA/Rego 的策略差异化配置示例，通过环境标签动态调整规则阈值：
# policy_allowed_registry.rego
package kubernetes.validating
# 环境标签从 AdmissionReview 中提取
env := input.request.object.metadata.labels.environment
# 允许的镜像仓库列表，按环境差异化
allowed_registries := {
"dev": {"docker.io/*", "localhost:5000/*"},
"test": {"docker.io/*", "registry.test.internal/*"},
"staging": {"registry.staging.internal/*"},
"prod": {"registry.prod.internal/*"}
}
# 规则：镜像必须来自允许的仓库
deny[msg] {
image := input.request.object.spec.containers[_].image
not startswith(image, allowed_registries[env][_])
msg := sprintf("环境 %v 不允许使用镜像: %v", [env, image])
}
# 规则：生产环境强制要求镜像签名
deny[msg] {
env == "prod"
image := input.request.object.spec.containers[_].image
not image_has_signature(image)
msg := sprintf("生产环境镜像 %v 缺少签名", [image])
}
避坑指南：不要将环境标签硬编码在策略规则中。应通过 ConfigMap 或外部数据源注入环境配置，否则每次环境变更都需要修改策略代码，违背了策略即代码的不可变原则。
4.5 策略差异化与 Runbook 联动部署实战
在 CI/CD 管道中，策略差异化与 Runbook 的联动部署通常包含以下步骤：
- 策略打包：将策略代码与环境参数模板打包为不可变制品，版本号与 Git commit 绑定。
- 环境映射：在部署时通过
--set environment=prod参数注入环境标签，策略引擎自动加载对应阈值。 - Runbook 触发：每个环境部署完成后，自动触发对应 Runbook 执行策略验证、回归测试或灰度验证。
- 结果回写：Runbook 执行结果（通过/失败/告警）回写到策略引擎的状态存储，用于晋升门禁判断。
- 自动回滚：生产环境策略验证失败时，Runbook 自动执行回滚操作，将策略版本恢复至上一稳定版本。
效率提升：使用 GitOps 模式管理策略配置，每次策略变更通过 Pull Request 发起，CI 自动生成差异化对比报告，Runbook 在合并后自动执行环境部署与验证，将策略交付周期从天级缩短到分钟级。
4.6 多环境策略审计与合规报告
策略差异化设计必须配套统一的审计与合规报告机制，确保每个环境的策略执行情况可追溯、可对比。建议采用以下报告结构：
| 环境 | 策略总数 | 生效规则数 | 违规次数 (24h) | 阻断次数 (24h) | 合规率 |
|---|---|---|---|---|---|
| 开发 | 45 | 32 (Audit) | 127 | 0 | — |
| 测试 | 45 | 40 (Audit+Warn) | 89 | 0 | — |
| 预发布 | 45 | 45 (Warn+Enforce) | 23 | 5 | 95.6% |
| 生产 | 45 | 45 (Enforce) | 3 | 3 | 99.8% |
通过上述报告，团队可以快速识别策略在不同环境的执行差异，发现开发环境违规次数过高时，应优化规则阈值或加强开发者培训；生产环境合规率低于 99% 时，需立即审查策略配置与 Runbook 联动逻辑。