Spring Boot 应用做密钥外置：Vault、K8s Secret 与环境变量到底怎么取舍？

【背景】 我负责一个 20 人团队的 Spring Boot 微服务（Java 17、Spring Boot 3.1，跑在 3 节点 K8s 1.28 上，自建集群、无云账号）。目前 DB 密码、第三方 API Key、JWT 签名密钥都写在 application-*.yml 里，靠 Jasypt 加密后提交到 Git。最近一次安全审计挂了 2 条：

• 密钥轮转要在 24h 内生效，不依赖应用发版；
• 密钥不得在 Git 历史里可追溯（哪怕密文）。

【现象 / 卡点】

1. 密钥轮转 = 改 Git + 全量发版，一次 1–2 小时，超窗；
2. 新同学 clone 仓库后，历史 commit 里能看到 Jasypt 密文，虽然解不开，但审计口径不认；
3. 第三方 API Key 想做到「每环境独立 + 可独立吊销」，目前做不到，全环境共用一把。

【已尝试与结果】

• 把 Jasypt 换成环境变量 + K8s Secret 挂载：能跑，但 Secret 本质是 base64 明文，etcd 里裸奔，审计仍不过；
• 看了 Vault 文档（AppRole + K8s Auth + KV v2），方案能对上需求，但团队没人运维过，担心引入新故障域（Vault 挂 = 全应用起不来）；
• 考虑过 AWS Secrets Manager / GCP Secret Manager，但我们是自建 K8s、没有云账号，走不通；
• 也想过 Sealed Secrets，但它的「单向加密」依赖 cluster-sealing-key，密钥轮转和吊销能力反而不如 Vault。

【期望得到的答案形态】 希望社区里跑过同类场景的同学给一个可落地的选型清单，重点：

1. 自建 K8s + 无云账号前提下，Vault / Sealed Secrets / 自研密钥网关 三者的运维成本、故障域、审计能力、轮转机制逐项对比，最好带踩坑点；
2. 密钥轮转的具体机制：应用侧是 pull 还是 push？缓存 TTL 怎么定？轮转时新旧密钥并存窗口怎么设计，避免 502？
3. 如果选 Vault，AppRole + K8s Auth 的落地步骤、HA 部署最小配置、PKI 是否要一起上（做 mTLS 用）；
4. 有没有更轻的替代方案（比如只把敏感项抽到独立 ConfigMap + RBAC 收敛 + etcd 加密），能同时满足上面 2 条审计要求？

不用贴完整代码，给决策依据 + 踩坑点 + 关键配置片段就行。