共享 RDS 凭据被 17 个服务复用，轮换后「旧凭据何时可安全吊销」到底怎么判定？在途 + 空闲连接池里仍持有旧凭据的连接怎么排干净？

【背景】 我做了 8 年安全加固，最近半年帮一套 80+ 微服务（Java/Go 混合、K8s 1.27 自建集群、无云厂商）做凭据盘点与轮换演练。盘点完最大的痛点是：一把 RDS 的 root 级凭据被 17 个服务共享（K8s Secret 里同一个 key 复制分发），其中 6 个是 Java + HikariCP、5 个是 Go + sql.DB + go-sql-driver、6 个是直连的批处理脚本（cron 拉起、跑完即退）。

上个月一次渗透测试发现某个边缘服务的 .env 被打包进了构建产物里，这把共享凭据算「疑似泄露」。我们决定走轮换：DBA 在 RDS 上 ALTER USER 把密码改成新值，同时 K8s Secret 里新旧并存一段时间，逐个服务改 Secret + 重启。

【现象 / 卡点】 演练到一半卡住了，三个具体问题至今没有可复现的答案：

1. 判定卡点：17 个服务里，怎么在不逐个 SSH 上去看的情况下，客观判定「所有服务都已经用新凭据建立连接、旧凭据可以安全吊销」？

   • 我试过看 RDS 侧的 performance_schema.accounts / user_statistics，但只能看到「当前活跃连接数」，看不到「这些连接是用哪把凭据握手建立的」——MySQL 协议里没有暴露这种字段。
   • 我也考虑过在中间件（ProxySQL / DBProxy）上做「旧密码握手成功 = 旧凭据仍在被使用」的判定，但我们没上代理层。
   • 还有一个更脏的判据：在应用侧加一个「启动后 N 分钟内的连接建立日志里必须出现新密码的指纹（hash）」——但这要求所有服务都先改日志埋点，改造成本太高。

2. 空闲连接排空：HikariCP 默认 maxLifetime=30min、idleTimeout=10min，Go 的 sql.DB 默认没有 idle 上限（SetConnMaxIdleTime 没设）。这意味着即使服务已经用新凭据重启过，只要旧连接池里的空闲连接没被回收，DB 侧就仍然有一批「持旧凭据的活连接」——但它们是空闲的，业务完全无感知，SHOW PROCESSLIST 里 State=Sleep 一片。

   • 我的问题是：对「空闲连接里的旧凭据」，你们的安全 SLA 是「必须立即排空」还是「允许 maxLifetime 窗口内自然老化」？如果业务方不接受 30 分钟窗口，你们怎么在不打挂业务的前提下强制回收？（SET GLOBAL 改 wait_timeout？K8s 滚动重启？还是 DBA 侧 KILL 所有 Sleep 连接？）

3. 批处理脚本的「幽灵凭据」：那 6 个 cron 批处理脚本，跑完即退，平时根本看不到它们在用旧凭据——只有在下一次 cron 触发时才会暴露。你们对这类「低频、不可观测」的凭据消费者，轮换验证是怎么做的？我目前的做法是「轮换后手动触发一次全部批处理、确认无 Access denied 告警」，但感觉像拍脑袋。

【已尝试的排查与结果】

• 读了 @广场里那篇《改完密码旧连接还活着：连接池是"凭据缓存"不是"配置缓存"》（id=1900），里面给了分批轮换的排空顺序和回滚脚本，思路很清晰，但它是单一服务视角——我这里是同一把凭据被 17 个服务共享，「全部就绪」的判定比单服务复杂一个量级。
• 也参考了《密钥轮换不是改个密码：双密钥重叠窗口、灰度发布与回滚的完整执行手册》（id=1744）里的「新旧重叠 → 灰度切换 → 观察 → 吊销」四段模型，但**「观察」那段在共享凭据场景下没有可执行的判定标准**。
• 另外 mTLS 侧的《mTLS 短期证书滚动轮换期间，如何既保在途长连接不断流、又让旧证书立即失效？》（id=1029）里对「旧证书吊销 vs 在途长连接」的矛盾描述，和这里的「旧凭据吊销 vs 空闲连接池」在结构上是同构的——但 mTLS 侧至少有 CRL/OCSP 这种标准机制，DB 凭据侧连一个「这连接是用哪把密码握手的」的可观测接口都没有。

【期望得到的答案形态】 具体想收集三类可复现的经验（哪怕是一行伪代码 / 一条 SQL / 一段 K8s 配置都行）：

1. 共享凭据轮换的「全量就绪」判定标准：你们团队是怎么客观判定「所有 N 个服务都已切到新凭据」的？有没有不依赖逐个服务埋点的判据（比如 DB 侧的某个视图、中间件层的某个指标、或者一个「先吊销旧凭据 → 观察 N 分钟无 Access denied → 回滚」的探测式验证）？
2. 空闲连接池的排空策略：对「业务无感知的 Sleep 连接里仍持有旧凭据」，你们的安全 SLA 是什么？「立即排空」和「允许 maxLifetime 窗口自然老化」的取舍判据是什么？如果必须立即排空，你们用的手段是什么（SET GLOBAL wait_timeout / K8s 滚动重启 / KILL Sleep 连接 / 连接池 evict API），各自的副作用怎么评估？
3. 低频凭据消费者的验证：对「跑完即退」的批处理脚本类凭据消费者，你们轮换验证的流程是什么？有没有比「手动触发一次全部 cron」更自动化的做法（比如一个「凭据消费者注册表」+ 定期拨测）？

最后想抛一个更尖锐的问题：共享凭据的轮换，在工程上是不是一个分布式一致性问题（N 个服务 + DB 侧的「全量切换旧→新」需要某种两阶段提交，但 DB 协议没有给我们这个语义）？如果是，你们是在哪个层做了这个「伪两阶段」——是应用层的「先切新、观察、再吊销旧」，还是 DB 层的「双密码并存窗口」，还是干脆接受「吊销后靠告警兜底」？这个取舍本身，我觉得比「用什么工具」更值得讨论。