Grafana OnCall插件在自签名证书环境下的配置问题解析

问题背景

在Kubernetes环境中部署Grafana OnCall插件时，当系统使用自签名证书并通过Nginx反向代理时，从1.8.13版本升级到1.13.6版本后出现了证书验证失败的问题。具体表现为插件无法与Grafana API建立安全连接，错误信息显示"x509: certificate signed by unknown authority"。

问题分析

这个问题本质上涉及两个技术层面的挑战：

1. 证书信任链问题：新版本的OnCall插件加强了对HTTPS连接的证书验证机制，不再默认信任自签名证书。当插件尝试通过HTTPS访问Grafana API时，由于无法验证自签名证书的合法性，导致连接被拒绝。

2. 内部通信路径问题：即使用户将CA证书嵌入Grafana容器，插件仍然尝试通过外部域名而非内部服务名(如grafana:3000)访问API，这会导致认证失败，因为内部服务通常配置了不同的认证机制。

解决方案

经过实践验证，可以通过以下两种方式解决此问题：

方法一：手动配置插件设置

通过直接调用Grafana API来配置OnCall插件，绕过证书验证环节：

curl -X POST 'https://admin:[e-mail]/grafana/api/plugins/grafana-oncall-app/settings' \
-H "Content-Type: application/json" \
-d '{
  "enabled":true,
  "jsonData":{
    "stackId":5,
    "orgId":100,
    "onCallApiUrl":"http://oncall:8080/",
    "grafanaUrl":"http://grafana:3000/"
  }
}'

关键点在于：

• 明确指定内部服务地址(http://grafana:3000和http://oncall:8080)
• 使用HTTP协议而非HTTPS，避免证书验证
• 直接配置必要的连接参数

方法二：配置证书信任(备选方案)

如果必须使用HTTPS连接，可以考虑：

1. 将自签名CA证书添加到容器的信任存储中
2. 配置Grafana和OnCall使用相同的证书体系
3. 确保内部服务名和外部域名都包含在证书的SAN中

版本差异说明

1.8.13版本之所以能正常工作，是因为该版本可能：

• 默认不严格验证证书
• 使用不同的内部通信机制
• 对错误处理更为宽松

而1.13.6版本增强了安全性，要求：

• 严格的证书验证
• 明确的连接配置
• 规范的错误处理

最佳实践建议

对于生产环境，建议：

1. 为内部服务配置合法的证书，而非自签名证书
2. 明确区分内部和外部通信端点
3. 在升级前测试证书配置
4. 文档化所有API端点配置

通过以上方法，可以确保Grafana OnCall插件在安全的环境中稳定运行，同时满足企业的合规性要求。