3. Secrets 管理基础：什么是 Secrets（密钥、令牌、证书），静态 vs 动态 Secrets
在云原生与蓝绿发布场景中，Secrets（敏感信息） 是系统安全的第一道防线。无论是数据库密码、API 令牌还是 TLS 证书，一旦泄露或版本错乱，轻则发布失败，重则引发安全事件。本章从定义出发，厘清三类核心 Secrets 的形态与生命周期，并重点对比静态与动态 Secrets 在蓝绿发布中的适用性。
3.1 什么是 Secrets
Secrets 泛指任何需要保密性、完整性、不可否认性的敏感数据。在 Kubernetes 及云原生生态中，Secrets 通常以 Base64 编码或加密形式存储，并通过 Volume 挂载或环境变量注入到 Pod 中。根据用途，可划分为以下三类：
| 类型 | 典型示例 | 核心用途 | 常见泄露风险 |
|---|---|---|---|
| 密钥（Key） | 数据库密码、、SSH 私钥 | 身份认证、数据加密 | 硬编码在代码仓库、日志输出 |
| 令牌（） | JWT、OAuth2 Access 、Service Account | 临时授权、服务间调用 | 令牌未设置过期时间、权限过大 |
| 证书（Certificate） | TLS/SSL 证书、mTLS 客户端证书 | 传输加密、双向身份验证 | 证书过期未轮换、私钥权限失控 |
3.2 静态 Secrets 与动态 Secrets
根据生成方式与生命周期，Secrets 可分为静态（Static）和动态（Dynamic）两大类。理解两者的差异，是设计自动化回滚策略的前提。
3.2.1 静态 Secrets
静态 Secrets 由管理员预先创建，存储在 Secret 存储后端（如 Kubernetes Secret、Vault 的静态 KV 引擎）中，生命周期通常以月或年为单位。典型场景包括：数据库 root 密码、第三方服务的长期 、自签 CA 证书。
- 优点： 实现简单，不依赖外部生成器；适合离线环境或低频变更场景。
- 缺点： 泄露后影响范围大；轮换需要手动或脚本触发，容易遗漏；在蓝绿发布中，静态 Secrets 的版本与应用版本解耦，回滚时容易造成凭证不匹配。
3.2.2 动态 Secrets
动态 Secrets 由授权引擎按需生成，具有租约（Lease）和自动过期特性。HashiCorp Vault、AWS Secrets Manager、CyberArk Conjur 等工具均支持动态 Secrets。典型场景包括：数据库临时用户、一次性 SSH OTP、短期 TLS 证书。
- 优点： 泄露后窗口极短；每次访问凭证唯一，便于审计；支持自动续期与撤销，天然适配蓝绿发布的快速回滚需求。
- 缺点： 引入外部依赖；需要处理租约续期逻辑；对应用代码有一定侵入性（需集成 SDK 或 Sidecar）。
3.3 静态 vs 动态 Secrets 对比表
| 维度 | 静态 Secrets | 动态 Secrets |
|---|---|---|
| 生命周期 | 长期（月/年） | 短期（分钟/小时） |
| 生成方式 | 管理员手动或 CI 预置 | 授权引擎按需生成 |
| 泄露影响 | 大（需立即轮换所有引用方） | 小（凭证自动过期） |
| 蓝绿发布适配性 | 低（版本绑定困难，回滚易错） | 高（每次发布生成新凭证，回滚自动失效） |
| 审计追溯 | 弱（多人共用同一凭证） | 强（每次请求可追踪到具体 Pod/用户） |
| 运维复杂度 | 低 | 中高（需管理租约、Sidecar、策略） |
3.4 静态与动态 Secrets 在蓝绿发布中的交互流程
下图展示了两种 Secrets 模式在蓝绿发布中的典型数据流差异。静态 Secrets 在发布前后使用同一份凭证，回滚时容易因凭证版本滞后导致旧版本无法连接后端；动态 Secrets 则为每个版本生成独立凭证，回滚时旧版本自动使用其原有租约，互不干扰。
3.5 蓝绿发布中的 Secrets 版本控制原则
基于上述对比，在蓝绿发布剧本中管理 Secrets 应遵循以下原则：
- 版本绑定： 每个发布版本应记录其使用的 Secrets 指纹（SHA256 或版本号），回滚时自动校验。
- 优先动态： 对于数据库、消息队列等核心中间件，优先使用动态 Secrets 并设置与发布窗口匹配的租约时长。
- 静态隔离： 若必须使用静态 Secrets，应为每个环境（蓝/绿）创建独立的 Secret 副本，避免共享。
- 自动化轮换： 静态 Secrets 应纳入 CI/CD 流水线，每次发布前自动轮换并更新引用。