Grafana Helm Chart 升级失败问题分析与解决方案

问题背景

在Grafana Helm Chart从7.0.22版本升级到7.1.0及更高版本时，许多用户遇到了升级失败的问题。错误信息主要涉及两个关键点：

1. 模板执行错误：UPGRADE FAILED: template: grafana/templates/secret.yaml:1:62: executing "grafana/templates/secret.yaml" at <.Values.env.GF_SECURITY_ADMIN_PASSWORD__FILE>: can't evaluate field GF_SECURITY_ADMIN_PASSWORD__FILE in type interface {}

2. 敏感信息验证错误：Sensitive key 'database.password' should not be defined explicitly in values. Use variable expansion instead

问题根源分析

这个问题的核心在于Grafana Helm Chart在7.1.0版本引入了一个新的安全验证机制，旨在防止敏感信息（如密码、密钥等）直接暴露在values.yaml文件中。这个验证机制通过assertNoLeakedSecrets参数控制，默认值为true。

验证机制会检查以下配置项：

• 数据库密码(database.password)
• OAuth客户端密钥(auth.*.client_secret)
• SMTP密码(smtp.password)
• 管理员密码(admin.password)

当这些配置项直接以明文形式出现在values.yaml中时，验证机制会阻止部署。

解决方案

临时解决方案

对于需要快速解决问题的用户，可以暂时关闭验证机制：

assertNoLeakedSecrets: false

推荐的安全解决方案

1. 使用Kubernetes Secrets

最佳实践是将敏感信息存储在Kubernetes Secrets中，然后通过以下方式引用：

envFromSecret: grafana-secrets

然后在grafana.ini配置中使用环境变量引用：

[auth.azuread]
client_id = ${CLIENT_ID}
client_secret = ${CLIENT_SECRET}

[database]
password = ${DB_PASSWORD}

2. 使用文件挂载方式

对于更复杂的安全需求，可以使用文件挂载方式：

extraSecretMounts:
- name: grafana-secrets
  secretName: grafana-secrets
  mountPath: /etc/secrets
  readOnly: true

然后在配置中使用文件引用：

[auth.azuread]
client_secret = $__file{/etc/secrets/client_secret}

3. 使用环境变量引用

对于简单的部署，可以使用环境变量引用：

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: grafana-secrets
      key: db-password

然后在grafana.ini中：

[database]
password = ${DB_PASSWORD}

版本兼容性说明

• 7.0.22及之前版本：无此验证机制
• 7.1.0-7.2.1版本：验证机制存在缺陷，可能导致合法配置也被阻止
• 7.2.2及之后版本：验证机制已修复，正确处理变量扩展和文件引用

最佳实践建议

1. 尽早升级到7.2.2+版本：修复版本已经解决了大多数验证问题
2. 保持assertNoLeakedSecrets为true：这是重要的安全功能
3. 使用Kubernetes原生Secret管理：避免在values.yaml中存储敏感信息
4. 考虑使用SealedSecrets或Vault：对于生产环境更安全的Secret管理方案
5. 测试环境先行：在升级前在测试环境验证配置

总结

Grafana Helm Chart的安全验证机制虽然最初引入了一些兼容性问题，但其设计初衷是为了提高部署安全性。通过采用推荐的Secret管理方案，用户既能保证安全性，又能顺利升级到最新版本。对于使用kube-prometheus-stack等包含Grafana的复合Chart的用户，需要确保包含的Grafana子Chart版本在7.2.2以上才能获得修复。