GitOps 密钥轮换同步成功不代表凭据已经更新一、密钥轮换容易半途而废GitOps 管理配置很方便但密钥轮换比普通配置更复杂。Secret 更新到集群不代表应用已经重新加载应用重新加载不代表旧连接已经断开新凭据可用也不代表旧凭据已经撤销。同步成功不代表凭据已经更新。二、先画轮换阶段flowchart TD A[生成新密钥] -- B[写入 Secret] B -- C[应用加载] C -- D[验证新凭据] D -- E[撤销旧凭据]每个阶段都要有验证点。跳过验证直接撤销旧凭据可能导致服务大面积失败。secret_rotation: create_new: required deploy_new: required verify_usage: required revoke_old: after_verify轮换不是一次 apply而是一个流程。三、应用是否热加载要确认有些应用读取挂载文件可以热更新有些只在启动时读取环境变量。对后者Secret 改了必须滚动重启。reload_policy: env_secret: rolling_restart mounted_file: app_reload_required external_secret: depends_on_operator不要假设所有应用都会自动感知 Secret 变化。四、双凭据窗口更安全很多外部系统支持同时保留新旧两个凭据。先让应用使用新凭据验证成功后再撤销旧凭据可以降低风险。dual_credential_window: enabled: true duration: 24h monitor_auth_failure: true轮换期间要监控认证失败、连接重建、错误率和实例版本。确认所有实例都使用新凭据后再收旧凭据。最后GitOps 状态和运行时状态要对齐。Git 显示同步成功只说明期望状态写入了集群不说明应用行为已经切换。密钥轮换还要处理回滚。新凭据如果验证失败应该能快速切回旧凭据而不是旧凭据已经被撤销。双凭据窗口本质上就是给回滚留空间。rotation_rollback: keep_old_credential_until_verified: true rollback_secret_version: recorded revoke_after_stable_window: true还要检查下游系统配额。有些第三方 API 创建新密钥有数量限制轮换流程要在创建前确认额度避免生成失败卡在中间状态。最后密钥轮换应该定期演练。等到泄露事件发生时才第一次跑流程几乎一定会漏步骤。还要明确哪些密钥可以自动轮换哪些必须人工确认。内部服务调用凭据可以高度自动化支付、域名、云账号根凭据这类高风险密钥则需要更严格审批。rotation_policy: internal_api_key: automated database_password: staged_rollout cloud_root_key: manual_approval轮换后要清理旧 Secret 版本和临时权限。很多泄露风险不是新凭据没生效而是旧凭据长期没有撤掉。最后轮换记录要进入审计系统。何时轮换、谁批准、哪些实例完成加载、旧凭据何时撤销都要能查。五、总结GitOps 密钥轮换要经过生成、同步、加载、验证和撤销旧凭据并根据应用能力选择热加载或滚动重启。同步成功不代表凭据已经更新。密钥轮换必须以运行时验证为准。