msdnmm 密码家族清理
起点是审查清单上的「五处明文」（MinIO root、Loki S3 key、streaming-pipeline 的 ES/DB 密码）。逐仓审计后发现真问题比清单大：同一个密码家族在公开仓（kubernetes + cloud-native-deploy）出现约 700 处，横跨 casdoor、dragonfly、harbor、juicefs、redis、postgres 的示例与脚本，而 VPS 上活着的 minio 用的正是这个家族。
处置（2026-08-17）
- VPS minio：轮换为强随机值 → 写入 Vault
secret/vps/minio；git 侧 compose 改占位符 - 集群 minio：新随机值 →
secret/k8s/minio，经 ESO 物化（见 ESO 接线） - 批量置换：730 处 / 124 文件 →
<REDACTED-20260817>，覆盖 kubernetes（含 archive——「原样保留」原则为安全让路并记录在案）、cloud-native-deploy 全仓、pipeline 仓、docker-deploy 的 minio 目录；终核 grep 为 0 - 老集群消费者（Loki S3 四组 key、旧默认密码）已随集群重建死亡，置换属于卫生动作
刻意未动与待办
- ecommerce 仓 20 份
configs/{dev,pre}.yml也在家族里：挂靠其 Config Center（现 control-tower）迁移轨道轮换，混改会破坏契约 - docker-deploy（已转私有）中 casdoor/postgres/redis/gorse 等 compose 仍是字面量真值：VPS 活口令与公开仓历史同源，逐个轮换列为待办
- cloud-native-deploy 与 pipeline 仓的 git 历史仍含明文（HEAD 已清）：是否重写待决策
- kubernetes 仓历史已用 git filter-repo 重写：用上下文串替换而非裸端口号（裸数字会误伤 CSV 数据）；重写后 HEAD 树哈希与原 HEAD 逐字节一致。教训：从 filter-repo 产物仓直接 push 会因缺旧对象在协商阶段挂死，fetch 回工作仓再推即秒过