grafana不加密存储密码而是用secret_key封装，密钥丢失会导致数据源连接失败；恢复需重填密码并固化密钥，无法逆向解密。
这个问题很关键，但需要先厘清一个常见误解：Grafana 本身不加密存储第三方数据源的密码，而是使用内置的 secret_key 对其进行加密封装（AES-256-GCM），用于防止配置被篡改或泄露后直接读取。一旦该密钥丢失或变更，Grafana 启动时将无法解密已保存的数据源凭据，表现为：
– 数据源显示“Password is encrypted and cannot be displayed”但测试连接失败
– 日志中出现类似 Failed to decrypt secure json data 或 invalid ciphertext 错误
– 所有含密码的数据源（如 MySQL、PostgreSQL、Prometheus Basic Auth、Elasticsearch 等）均无法验证或查询
确认 secret_key 是否真的丢失或不匹配
检查 Grafana 配置文件（通常是 /etc/grafana/grafana.ini 或容器内 /etc/grafana/grafana.ini）中的 [security] 区块：
- 若存在
secret_key = xxx且你确定该值已被修改/覆盖/清空 → 属于密钥丢失 - 若该行被注释（
;secret_key = ...）或完全不存在 → Grafana 启动时会自动生成一个随机密钥并写入grafana.db的setting表，但每次重启都可能变化 → 属于密钥不稳定 - 若使用 Docker 且未挂载配置或未设环境变量，每次重建容器都会生成新密钥 → 实质是密钥不可持续
核心恢复原则：密钥不可逆，凭据必须重输
⚠️ 重要前提：加密后的凭据无法从数据库中还原出原始密码。AES-GCM 是单向封装，没有密钥就无法解密 —— 这不是漏洞，而是设计安全机制。因此，所谓“恢复”，本质是重建可信密钥链 + 人工重填密码，而非技术性解密。
分场景应对方案
场景一：你仍保留旧 secret_key 值（例如备份了旧配置）
- 停止 Grafana 服务：
systemctl stop grafana-server（Linux）或docker stop grafana - 编辑
grafana.ini，取消注释并填回原始secret_key值 - 确保
[paths]中data路径与数据库位置一致（如/var/lib/grafana） - 启动服务，Grafana 将用原密钥成功解密已有凭据，所有数据源自动恢复正常
场景二：secret_key 已彻底丢失，且你有管理员权限可登录 Grafana
- 登录 Grafana Web UI（用其他可用账号，或重置 admin 密码后登录）
- 逐个进入「Configuration → Data Sources」→ 编辑每个异常数据源
- 在「Basic Auth」或「Password」字段中重新输入明文密码（即使界面显示为星号，输入即覆盖加密值）
- 点击「Save & Test」，Grafana 会用当前有效的
secret_key重新加密并保存 - 建议同步导出数据源配置（JSON）作为备份：
Dashboard settings → Export
场景三：完全无法登录，且无旧密钥备份（最严峻情况）
- 先通过
grafana-cli admin reset-admin-password或直接修改grafana.db恢复 admin 登录能力 - 再按「场景二」操作重填所有数据源密码
- 为防复发，立即在
grafana.ini中固化密钥：[security]secret_key = your-32-byte-random-string-here
（可用openssl rand -base64 32生成） - 将该配置文件纳入版本管理或备份体系，禁止随服务重启漂移
预防措施：避免再次发生
✅ 在首次部署 Grafana 时，就手动设置强 secret_key 并存档
✅ 使用配置即代码（GitOps）管理 grafana.ini，禁止裸机部署无密钥
✅ Docker 环境下，始终通过 -e GF_SECURITY_SECRET_KEY=... 注入，而非依赖默认行为
✅ 定期导出数据源配置（含脱敏结构），不依赖加密字段“可恢复”假象
✅ 若使用外部密钥管理（如 HashiCorp Vault），启用 Grafana 的 secure_socks_proxy 或插件集成，而非仅靠内置密钥
