安全模型

注意在我们深入探讨以下技术细节之前,我们想强调 Prometheus 作为监控系统,收集并提供其监控系统的信息。因此,Prometheus 组件提供的 HTTP 端点不应暴露在互联网等公共网络上(除非您清楚自己在做什么并已采取适当措施)。这包括(但不限于)仪表化二进制文件的 /metrics 端点、服务器组件的各种 API 端点以及用 Go 实现的服务器组件的 /pprof 端点。此外,通过向这些端点发送请求,很容易使服务器过载并最终导致拒绝服务(DoS)。

Prometheus 是一个复杂的系统,包含许多组件,并与许多其他系统集成。它可以在各种受信任和不受信任的环境中部署。

本页描述了 Prometheus 的一般安全假设以及某些配置可能启用的攻击向量。

与任何复杂系统一样,几乎可以肯定会发现一些错误,其中一些与安全相关。如果您发现一个安全漏洞,请私下报告给相关仓库的 MAINTAINERS 中列出的维护者,并抄送 [email protected]。我们将尽快修复此问题,并与您协调发布日期。您可以选择是否希望公开表彰您的努力,以及是否希望提及您的姓名。

自动化安全扫描器

致安全扫描器用户特别提示:请注意您生成的报告。大多数扫描器都是通用的,会产生大量误报。我们收到的报告越来越多,并且需要大量工作才能逐一审查并给予您期望的回复。Go 和 NPM 依赖扫描器的问题尤其严重。

为节省我们和我们的时间,请不要提交原始报告。相反,请附上分析报告,说明哪些具体结果适用于我们以及原因。

Prometheus 由志愿者维护,而非公司。因此,安全问题的修复是尽力而为的。我们力求在 7 天内发布 Prometheus、Alertmanager、Node Exporter、Blackbox Exporter 和 Pushgateway 的安全修复。

Prometheus

假定不受信任的用户可以访问 Prometheus HTTP 端点和日志。他们可以访问数据库中包含的所有时间序列信息,以及各种操作/调试信息。

还假定只有受信任的用户才能更改命令行、配置文件、规则文件以及 Prometheus 和其他组件运行时环境的其他方面。

Prometheus 抓取哪些目标、抓取频率以及使用哪些其他设置完全由配置文件决定。管理员可以决定使用服务发现系统中的信息,这与重新标记结合起来,可能会将部分控制权授予任何能够修改该服务发现系统中数据的人。

抓取的目标可能由不受信任的用户运行。默认情况下,目标不应能够暴露冒充不同目标的数据。honor_labels 选项会移除此保护,某些重新标记设置也可能如此。

从 Prometheus 2.0 开始,--web.enable-admin-api 标志控制对管理 HTTP API 的访问,该 API 包含删除时间序列等功能。此功能默认禁用。如果启用,管理和变更功能将可通过 /api/*/admin/ 路径访问。--web.enable-lifecycle 标志控制 Prometheus 的 HTTP 重载和关机。此功能也默认禁用。如果启用,它们将可通过 /-/reload/-/quit 路径访问。

在 Prometheus 1.x 中,/-/reload 和对 /api/v1/series 使用 DELETE 操作可供任何有权访问 HTTP API 的用户使用。/-/quit 端点默认禁用,但可以通过 -web.enable-remote-shutdown 标志启用。

远程读取功能允许任何有 HTTP 访问权限的用户向远程读取端点发送查询。例如,如果 PromQL 查询最终直接针对关系数据库运行,那么任何有能力向 Prometheus 发送查询(例如通过 Grafana)的用户都可以对该数据库运行任意 SQL。

Alertmanager

任何有权访问 Alertmanager HTTP 端点的用户都可以访问其数据。他们可以创建和解决告警。他们可以创建、修改和删除静默。

通知发送到哪里由配置文件决定。在某些模板设置下,通知可能会发送到告警定义的目标。例如,如果通知使用告警标签作为目标电子邮件地址,那么任何能向 Alertmanager 发送告警的人都可以向任何电子邮件地址发送通知。如果告警定义的目标是可模板化的秘密字段,那么任何有权访问 Prometheus 或 Alertmanager 的人都可以查看这些秘密。

任何可模板化的秘密字段都旨在用于上述用例中的路由通知。它们不应作为通过模板文件功能将秘密与配置文件分离的方式。存储在模板文件中的任何秘密都可能被任何能够在 Alertmanager 配置文件中配置接收器的人窃取。例如,在大型设置中,每个团队可能拥有一个他们完全控制的 Alertmanager 配置文件片段,然后这些片段被组合成完整的最终配置文件。

Pushgateway

任何有权访问 Pushgateway HTTP 端点的用户都可以创建、修改和删除其中包含的指标。由于 Pushgateway 通常在启用 honor_labels 的情况下被抓取,这意味着任何有权访问 Pushgateway 的人都可以创建 Prometheus 中的任何时间序列。

--web.enable-admin-api 标志控制对管理 HTTP API 的访问,该 API 包含清除所有现有指标组等功能。此功能默认禁用。如果启用,管理功能将可通过 /api/*/admin/ 路径访问。

Exporter

Exporter 通常只与一个配置好的实例通信,使用一组预设的命令/请求,这些命令/请求不能通过其 HTTP 端点进行扩展。

还有一些 Exporter,例如 SNMP 和 Blackbox Exporter,它们从 URL 参数获取目标。因此,任何有权访问这些 Exporter 的用户都可以让它们向任意端点发送请求。由于它们也支持客户端认证,这可能导致秘密泄露,例如 HTTP 基本认证密码或 SNMP 团体字符串。像 TLS 这样的挑战-响应认证机制不受此影响。

客户端库

客户端库旨在包含在用户的应用程序中。

如果使用客户端库提供的 HTTP 处理程序,恶意请求到达该处理程序不应导致超出额外负载和抓取失败之外的问题。

认证、授权和加密

Prometheus 和大多数 Exporter 支持 TLS,包括通过 TLS 客户端证书进行客户端认证。有关配置 Prometheus 的详细信息,请参见此处

Go 项目共享相同的 TLS 库,该库基于 Go 的 crypto/tls 库。我们默认使用 TLS 1.2 作为最低版本。我们对此的策略基于 Qualys SSL Labs 的建议,力求在默认配置和正确提供的证书下达到 'A' 级,同时尽可能地遵循 Go 的上游默认设置。达到该等级可在完美安全性和可用性之间取得平衡。

未来将在 Java Exporter 中添加 TLS 支持。

如果您有特殊的 TLS 需求,例如不同的密码套件或旧版 TLS,您可以调整最低 TLS 版本和密码,只要该密码在 crypto/tls 库中未被 标记为不安全。如果这仍然不适合您,当前的 TLS 设置允许您在服务器和具有特殊需求的反向代理之间建立安全隧道。

HTTP 基本认证也受支持。基本认证可以在没有 TLS 的情况下使用,但这会导致用户名和密码在网络上以明文形式暴露。

在服务器端,基本认证密码使用 bcrypt 算法以哈希形式存储。您有责任选择符合您安全标准的轮数。更多的轮数会使暴力破解更加复杂,但代价是消耗更多的 CPU 资源和更长的请求认证时间。

各种 Prometheus 组件支持客户端认证和加密。如果提供了 TLS 客户端支持,通常还有一个名为 insecure_skip_verify 的选项,用于跳过 SSL 验证。

API 安全

由于管理和变更端点旨在通过 cURL 等简单工具访问,因此没有内置的 CSRF 保护,因为这会破坏此类用例。因此,在使用反向代理时,您可能希望阻止此类路径以防止 CSRF。

对于非变更端点,您可能希望在反向代理中设置 CORS 头部(例如 Access-Control-Allow-Origin)以防止 XSS

如果您正在编写包含来自不受信任用户输入(例如控制台模板的 URL 参数,或您自行构建的内容)的 PromQL 查询,并且这些用户不应能够运行任意 PromQL 查询,请确保任何不受信任的输入都经过适当转义以防止注入攻击。例如,如果 <user_input>"} or some_metric{zzz=",则 up{job="<user_input>"} 将变为 up{job=""} or some_metric{zzz=""}

对于使用 Grafana 的用户请注意,仪表盘权限并非数据源权限,因此在代理模式下不会限制用户运行任意查询的能力。

秘密

非秘密信息或字段可能通过 HTTP API 和/或日志可用。

在 Prometheus 中,从服务发现检索到的元数据不被视为秘密。在整个 Prometheus 系统中,指标不被视为秘密。

配置文件中包含秘密的字段(在文档中明确标记为秘密的字段)不会在日志中或通过 HTTP API 暴露。秘密不应放置在其他配置字段中,因为组件通常会通过其 HTTP 端点暴露其配置。用户有责任保护磁盘上的文件免受不必要的读取和写入。

依赖项使用的其他来源的秘密(例如,EC2 服务发现使用的 AWS_SECRET_KEY 环境变量)可能会因我们无法控制的代码或因其存储位置的暴露功能而暴露。

拒绝服务

为应对过载或昂贵的查询,已采取了一些缓解措施。但是,如果提供了过多或过于昂贵的查询/指标,组件将崩溃。组件被受信任用户意外关闭的可能性比恶意行为更大。

用户有责任确保为组件提供充足的资源,包括 CPU、内存、磁盘空间、IOPS、文件描述符和带宽。

建议监控所有组件是否出现故障,并在故障时自动重启它们。

本文档考虑的是从原始源代码构建的纯净二进制文件。如果您修改 Prometheus 源代码,或在自己的代码中使用 Prometheus 内部(超出官方客户端库 API),则此处提供的信息不适用。

构建过程

Prometheus 的构建管道运行在第三方提供商上,Prometheus 开发团队的许多成员以及这些提供商的员工都可以访问。如果您担心二进制文件的确切来源,建议您自行构建,而不是依赖项目提供的预构建二进制文件。

Prometheus-社区

Prometheus-社区 组织下的仓库由第三方维护者支持。

如果您在 Prometheus-社区 组织中发现安全漏洞,请私下报告给相关仓库的 MAINTAINERS 中列出的维护者,并抄送 [email protected]

该组织下的某些仓库可能具有与本文档中介绍的不同安全模型。在这种情况下,请参阅这些仓库的文档。

外部审计

本页内容