Alertmanager数据源自定义CA证书配置问题

概述

在 SRE 实践中，确保告警通道的完整性和安全性至关重要。一个常见场景是将 Grafana 与使用由私有证书颁发机构（CA）签名的 TLS 证书的外部 Alertmanager 实例进行集成。本文档详细阐述了在 Grafana 中配置此类 Alertmanager 数据源时可能遇到的一个具体问题：尽管“测试并保存”操作成功，但实际告警发送因 TLS 验证失败而中断。理解此问题有助于 SRE 团队诊断告警流中断的根源，并采取安全的配置方式。

核心概念

在深入问题之前，需要明确几个关键概念：

TLS 客户端验证：当 Grafana（作为客户端）向 Alertmanager（作为服务器）发送 HTTPS 请求时，客户端需要验证服务器证书的有效性。这包括检查证书是否由受信任的 CA 签名、证书是否过期、证书域名是否匹配等。如果客户端不识别签名 CA，则验证失败。
自定义 CA 证书：当 Alertmanager 使用由组织内部私有 CA 签发的证书时，Grafana 服务器必须配置该私有 CA 的根证书（或中间证书链），以将其加入受信任列表。
Grafana 数据源 TLS 配置：Grafana 数据源配置界面提供了 TLS 相关选项，如“跳过 TLS 验证”（不安全）和“使用 CA 证书”。后者允许用户粘贴自定义 CA 证书的内容，旨在让 Grafana 在后续请求中信任由该 CA 签发的服务器证书。
x509 验证失败：日志中的错误信息 x509: certificate signed by unknown authority 明确指出，发送告警的代码路径尝试验证 Alertmanager 服务器证书时，找不到颁发该证书的 CA 信息，导致 TLS 握手失败。

实践

问题现象

用户在 Grafana 13.0.1 中配置了一个指向外部 Alertmanager 的数据源，并执行了以下操作：

在“认证”部分启用“使用 CA 证书”选项。
粘贴了由私有 CA 签发的 Alertmanager 服务器证书所对应的根 CA 证书。
点击“测试并保存”，操作成功，日志也显示了来自 Alertmanager 反向代理的健康检查记录。
在“警报设置”中激活了该数据源。
当有告警触发时，Grafana 的 ngalert.sender.external-alertmanager 组件尝试向 Alertmanager 发送告警，但日志中反复出现 TLS 验证错误，告警无法送达。
临时解决方案是启用“跳过 TLS 验证”，但这会禁用所有证书验证，在生产环境中引入安全风险。

根本原因分析

根据提供的日志和问题描述，问题的根本原因是 Grafana 中负责发送告警的组件（ngalert.sender.external-alertmanager）在初始化或执行过程中，并未正确加载或应用用户在数据源配置中提供的自定义 CA 证书。这很可能是一个代码缺陷。

具体来说：

“测试并保存”功能可能使用一个独立的、正确加载了自定义 CA 证书的 HTTP 客户端进行验证。
而负责实际告警发送的后台服务（sender）在创建其 HTTP 客户端时，可能遗漏了从数据源配置中读取并应用 TLSConfig 中的 CA 字段这一步骤，导致它使用默认的系统信任存储，从而无法识别私有 CA。
日志信息 tls: failed to verify certificate: x509: certificate signed by unknown authority 是 Go 语言标准库 crypto/tls 在验证失败时给出的典型错误，证实了客户端确实没有信任用于签名的 CA。

临时解决方案与注意事项

目前，最直接的临时解决方案是勾选数据源配置中的 “跳过 TLS 验证” 选项。

警告：此操作会禁用 TLS 证书验证，使 Grafana 容易受到中间人攻击。强烈不建议在任何处理敏感数据或控制关键操作的生产环境中长期使用此选项。应将其仅作为临时 workaround，直到官方修复发布。

根本解决方法

等待官方修复：该问题已被报告为 Grafana 的一个 bug（Issue #124980）。最安全的解决方法是关注该 issue 的进展，并在后续的 Grafana 版本更新中（可能是在 v13.0.2 或更高版本）应用官方补丁。
自行构建/打补丁：对于无法立即升级的环境，具备能力的团队可以参考 issue 中的讨论，尝试定位并修复相关代码（可能位于 pkg/services/ngalert/sender 相关模块），然后自行构建 Grafana 二进制文件。

SRE 要点

与可靠性的关联

此问题直接影响系统的告警可靠性。告警通道的失效意味着运维团队可能无法及时感知系统故障，延长了平均故障检测时间（MTTD），进而可能延长平均修复时间（MTTR），对服务等级目标（SLO）造成冲击。在 SRE 实践中，必须确保监控和告警管道本身是高度可靠的。

最佳实践与常见反模式

最佳实践：
- 验证告警路径：配置外部数据源后，除了使用“测试”按钮，应定期通过注入模拟告警来验证端到端的告警投递是否成功。
- 监控告警发送失败：应配置对 Grafana 自身日志中 ngalert.sender.external-alertmanager 错误的监控和告警，确保告警通道失效能被及时发现。
- 保持软件更新：及时应用安全更新和 bug 修复，以解决已知的安全和功能缺陷。
常见反模式：
- 滥用“跳过 TLS 验证”：为了快速解决问题而永久禁用 TLS 验证，这是严重违反安全最佳实践的行为，会引入不必要的风险。
- 忽略端到端测试：仅依赖配置界面的“测试成功”，而未在真实或模拟的生产环境中验证告警的实际投递流程。