AI 平台密钥轮换：双凭证过渡、工作负载身份与零停机撤销

AI 平台往往聚集了比普通应用更多的敏感凭证：模型供应商 API Key、对象存储访问密钥、向量数据库密码、模型仓库 token、Webhook 签名密钥、KMS 权限和服务间证书。它们若散落在环境变量、CI 日志、Notebook 与人工脚本中，即使团队规定“每九十天轮换”，真正执行时也很难回答哪些实例仍在使用旧值、撤销会不会中断推理、泄露后需要影响哪些租户。

密钥轮换首先是资产和依赖管理，而不是定时生成随机字符串。凭证目录至少记录所有者、用途、发行系统、消费者、权限范围、创建与到期时间、轮换方式、最后验证时间和应急联系人。扫描代码仓库只能发现一部分风险，还要检查 CI 变量、Kubernetes Secret、部署平台、Notebook、备份和人工运维终端。目录中的每项都应映射到具体工作负载身份，无法确认消费者的密钥不能被视为“没人用”。

优先消灭长期静态凭证

同一云环境内，优先使用工作负载身份、短期令牌或 mTLS，让 Pod 根据服务账号换取最小权限凭证，而不是把云访问密钥写进 Secret。对数据库和内部服务使用动态凭证，按需签发并自动过期。即使短期令牌泄露，攻击窗口也比永久 Key 小，撤销还能绑定具体工作负载。

外部模型供应商不一定支持联合身份，仍需静态 API Key。此时每个环境、应用和用途使用独立密钥，不共享“公司总 Key”；权限与消费上限设置到最低，供应商侧启用异常用量告警。相关基础原则可参考 密钥管理，而服务身份、用户身份与供应商凭证的区分可结合 MCP Server 鉴权边界。

Kubernetes Secret 只是分发对象，不天然等于安全保管库。它需要静态加密、严格 RBAC、审计和备份保护；能够读取 Pod 或在命名空间创建工作负载的主体，通常也可能间接获得 Secret。Git 中只保存外部密钥引用或加密后的声明，明文永远不进入镜像层和构建缓存。

用双凭证完成零停机切换

支持并存凭证的系统采用四阶段轮换。第一步创建新凭证 B，权限不超过旧凭证 A，并保持 A 有效。第二步将 B 发布到密钥管理系统，触发消费者刷新；第三步通过服务端认证日志确认所有预期实例都在使用 B，同时查找仍使用 A 的调用。第四步在覆盖一个完整业务周期和回滚窗口后撤销 A，并验证 A 确实无法再认证。

T0  issue B, A remains active
T1  distribute B with version=42
T2  workloads reload and prove successful use of B
T3  usage of A reaches zero for the observation window
T4  revoke A, run negative authentication test

“配置已更新”不是切换证据。滚动部署可能漏掉暂停的 CronJob、缩到零的 worker、故障区域或长时间运行的 Notebook。消费者应在指标中暴露不敏感的凭证版本或指纹，不能输出密钥本身。平台按工作负载期望清单检查版本收敛，休眠任务在下一次启动前也必须取得 B。

不支持双凭证的上游需要代理层或维护窗口。可以先让内部网关持有上游新旧凭证，业务工作负载只使用短期内部身份，由网关完成原子切换；若只能硬切，提前缩短应用侧凭证缓存 TTL，排空使用旧认证状态的长连接与长任务，并准备立即恢复 A 的路径。不要同时修改密钥、网络策略和客户端版本，否则失败时无法判断原因。

让应用动态刷新而不是依赖重启

Secret 通过卷更新时，应用必须监听文件变化并原子重载；环境变量不会自动改变，必须滚动重启。无论哪种方式，都要处理连接池、长流和在途请求：新连接使用 B，已有连接在截止时间内排空，认证失败时最多做一次受控刷新，不能无限重试把上游打爆。

密钥代理或 sidecar 应先把新值写入临时文件、校验权限后原子替换，避免应用读到半写文件。刷新失败时继续使用尚未撤销的 A 并告警；如果 A 已到期，则进入明确的不可用状态，而不是回退到镜像中的默认密钥。健康检查区分“进程存活”和“必需凭证可用”，但不能在探针响应中泄露任何版本之外的信息。

轮换控制器本身权限要更小：生成者、批准者、分发者和撤销者尽量分离，高风险生产密钥要求双人审批。所有动作写入不可篡改审计，记录谁在何时为哪个逻辑密钥创建了哪个版本、哪些工作负载确认切换、何时撤销旧值。日志只存密钥 ID 和单向指纹，错误堆栈也要经过脱敏。

泄露响应不是普通周期轮换

发现凭证进入 Git、日志或第三方工单时，不应等待标准观察窗口。先判断权限和调用范围，立即阻止继续暴露，生成替代凭证并切换关键消费者，然后尽快撤销旧值。并行查询供应商和内部审计日志，识别异常来源、时间、模型调用、数据访问与成本；必要时暂停相关租户或出口。删除 Git 最新提交中的字符串不足以消除历史、fork、缓存和构建产物里的副本。

泄露后的新密钥不能通过原来已被攻破的同一路径分发，先修复根因再恢复自动化。若怀疑工作负载身份或控制面被攻破，要扩大到下游派生令牌、签名密钥和会话凭证，而不是只换表面 API Key。AI 供应链安全 有助于检查镜像、CI 与依赖路径，云灾难恢复 则提醒团队确保备用区域能取得新凭证但无法读取已撤销版本。

定期演练撤销而非只演练创建

每次轮换都自动执行正向和负向验证：B 能完成最小权限操作，A 在撤销后必须失败，超范围操作即使使用 B 也必须失败。监控旧指纹调用、认证错误、刷新延迟、未收敛工作负载、即将过期凭证和异常消费。至少每季度选择一种关键凭证演练“供应商 Key 已泄露”，从告警开始计时，验证发现、签发、部署、撤销、取证和业务恢复。

最终目标不是让表格里的轮换日期变新，而是证明每个消费者能在不中断服务的情况下迁移、旧凭证确实失效、权限没有扩大、审计能复原全过程。只有创建和撤销都自动化，密钥才真正拥有生命周期，而不是一段被不同系统反复复制的字符串。

延伸阅读

• 密钥管理
• MCP Server 鉴权边界
• AI 供应链安全
• 云灾难恢复