4. Secrets版本控制必要性：配置漂移、回滚一致性、审计合规要求

在蓝绿发布场景中，Secrets（密钥、凭证、令牌等敏感配置）的管理往往被忽视，直到出现生产事故才被重视。与普通应用代码不同，Secrets的变更无法通过常规的Git diff直观感知，且其生命周期与容器实例、编排配置紧密耦合。本章从三个核心维度阐述为何必须对Secrets实施严格的版本控制。

4.1 配置漂移：蓝绿环境间的隐形裂缝

配置漂移（Configuration Drift）是指同一套应用在不同环境（蓝/绿）或不同时间点，因手动修改、自动轮换或编排差异导致Secrets实际值偏离预期版本的现象。在蓝绿发布中，这种漂移会直接破坏流量切换的可靠性。

配置漂移的常见成因包括：

• 手动修补： 通过Kubernetes Secret对象或Vault UI直接修改，绕过版本管理。
• 自动轮换策略： 密钥轮换服务仅更新部分环境，或轮换时间窗口不一致。
• 编排差异： 蓝绿环境的Helm values或Kustomize overlay引用了不同版本的Secret源。
• 回滚残留： 回滚应用代码时未回滚Secrets，导致新旧版本混合。

4.2 回滚一致性：代码回滚≠配置回滚

蓝绿发布的核心优势之一是快速回滚。然而，如果Secrets版本与应用版本脱钩，回滚操作将变得极其危险。回滚一致性要求：当应用代码回滚到某个历史版本时，其所依赖的Secrets也必须同步回滚到该版本对应的状态。

4.3 审计合规要求：不可抵赖的变更轨迹

在金融、医疗、政务等监管严格的行业中，对敏感配置的每一次访问和修改都必须留下可审计的痕迹。Secrets版本控制是实现审计合规的基础设施。

审计合规对Secrets管理的具体要求包括：

1. 变更可追溯： 谁、在什么时间、通过什么方式、修改了哪个Secrets的哪个字段。
2. 版本可比较： 能够对比任意两个版本之间的差异，快速定位引入问题的变更。
3. 回滚可证明： 回滚操作本身需要记录，且回滚后的Secrets状态必须与历史审计日志一致。
4. 访问可控制： 基于最小权限原则，只有授权实体（CI/CD管道、特定服务账户）才能读取或写入特定版本的Secrets。

4.4 版本控制的核心收益总结