从 etcd 里直接 get 一个 Secret，value 解 base64 就是数据库明文密码，审计要求加密存储。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，Secret 默认只做 base64 编码，etcd 里的 value 没有加密，能读到 etcd 数据文件或快照的人可以直接还原。base64 不是加密，只是传输格式。
「Secret 明文存储」这类改动最怕改一半，回滚脚本先准备好，再动生产。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
etcdctl get /registry/secrets/default/db-secret --print-value-only
kubectl get secret db-secret -o jsonpath='{.data.password}' | base64 -d
权限不要一口气开到最大，先加到够用再往上试，范围小才好收。把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。
改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
具体做法是，生成 EncryptionConfiguration 选 aescbc 或 kms provider；给 kube-apiserver 加 encryption-provider-config 并重启；用 kubectl get secret 触发一次重写 确认前缀变成 k8s:enc；把旧快照按敏感数据销毁 轮换一遍密码。
最后用这个标准收尾，再 get 同一路径时 value 以 k8s:enc:aescbc 开头 base64 解不出明文。