1. Secrets 管理基础：什么是 Secrets、生命周期与重要性
在蓝绿发布与自动化运维体系中，Secrets 是任何需要被保护的非公开敏感数据。一旦 Secrets 泄露，攻击者可以伪装成合法服务、窃取数据或篡改发布流程。本节从定义、生命周期和管理价值三个维度建立基础认知。
1.1 什么是 Secrets
Secrets 是用于身份认证、加密通信或授权访问的敏感凭证。在蓝绿发布场景中，Secrets 通常出现在以下三类形态中：
| 类型 | 典型用途 | 蓝绿发布中的风险点 |
|---|---|---|
| 密钥 (Key) | API 签名、数据加密、JWT 签发 | 新旧版本共用同一密钥导致签名冲突或回滚后密钥失效 |
| 令牌 () | 服务间认证、CI/CD 系统鉴权 | 令牌在蓝环境切换时未及时刷新，绿环境仍使用过期令牌 |
| 证书 (Certificate) | TLS/mTLS 双向认证、代码签名 | 证书绑定 IP 或 DNS 名称，蓝绿流量切换后证书域名不匹配 |
关键区分：Secrets 与配置项（ConfigMap）不同。配置项可以明文存储，Secrets 必须加密存储、传输和使用。在蓝绿发布中，误将 Secrets 放入 ConfigMap 是常见故障根因。
1.2 Secrets 生命周期
一个完整的 Secrets 生命周期包含六个阶段，每个阶段在蓝绿发布自动化中都有对应的故障模式：
- 生成 (Generate) — 创建密钥对、签发证书、生成随机令牌。故障点：弱随机数导致可预测。
- 存储 (Store) — 写入专用 Secrets 存储（Vault、AWS Secrets Manager、K8s Secrets）。故障点：明文落盘或权限配置过宽。
- 分发 (Distribute) — 将 Secrets 注入到蓝/绿环境的 Pod、容器或进程。故障点：蓝绿环境使用同一份 Secrets 副本导致版本混乱。
- 使用 (Use) — 运行时读取 Secrets 进行认证或解密。故障点：Secrets 轮换后运行中进程未重新加载。
- 轮换 (Rotate) — 定期或事件驱动地更换 Secrets。故障点：蓝绿切换期间轮换导致新旧版本各持有不同 Secrets。
- 吊销 (Revoke) — 删除或禁用已泄露或过期的 Secrets。故障点：吊销后未通知所有运行实例，导致服务中断。
实践建议：在蓝绿发布流水线中，将 Secrets 版本号作为发布元数据的一部分。每次切换前校验蓝绿两套环境的 Secrets 版本是否一致，避免因版本偏差导致认证失败。
1.3 Secrets 管理的重要性
在蓝绿发布自动化中，Secrets 管理失效会直接导致以下三类严重后果：
- 安全入侵：硬编码的 Secrets 被提交到代码仓库，攻击者通过扫描公开仓库获取凭证，进而控制整个 CI/CD 流水线。
- 发布中断：蓝绿切换时，新环境无法正确读取 Secrets，导致服务启动失败或认证拒绝，回滚成本急剧上升。
- 合规风险：PCI-DSS、HIPAA、SOC2 等标准要求 Secrets 必须加密存储、定期轮换且访问可审计。未达标可能面临罚款或吊销资质。
真实案例：某金融科技公司在蓝绿发布中，绿环境使用了与蓝环境相同的数据库密码。当蓝环境进行密码轮换后，绿环境因持有旧密码导致数据库连接池全部失效，回滚耗时 47 分钟，影响线上交易约 12 万笔。根因是 Secrets 未按环境隔离存储。
1.4 蓝绿发布中的 Secrets 管理原则
基于上述生命周期和风险分析，在蓝绿发布自动化中应遵循以下四项基本原则：
| 原则 | 说明 | 实施要点 |
|---|---|---|
| 环境隔离 | 蓝环境和绿环境使用独立的 Secrets 存储路径或命名空间 | K8s 中为每个环境创建独立的 Namespace 和 Secret 资源 |
| 版本绑定 | Secrets 版本与发布版本绑定，切换时自动校验 | 在 Helm Chart 或部署清单中声明 Secrets 版本标签 |
| 自动轮换 | 在发布窗口期自动触发 Secrets 轮换，避免手动操作 | 集成 Vault 或 AWS Secrets Manager 的轮换 API |
| 审计追溯 | 所有 Secrets 的读取、分发、轮换操作记录日志 | 启用审计日志并接入 SIEM 系统 |
落地检查清单：在每次蓝绿发布前，自动化脚本应执行三项检查——(1) 蓝绿环境 Secrets 路径是否独立；(2) 当前使用的 Secrets 版本是否与发布清单匹配；(3) 轮换窗口是否与流量切换窗口错开至少 5 分钟。