/metrics 端点、服务端组件的各种 API 端点以及用 Go 实现的服务端组件的 /pprof 端点。此外，通过向这些端点发送请求，很容易导致服务端过载并最终造成 DoS (拒绝服务)。Prometheus 是一个复杂的系统，包含许多组件并与许多其他系统集成。它可以部署在各种受信任和不受信任的环境中。
本页描述了 Prometheus 的一般安全假设以及某些配置可能带来的攻击向量。
与任何复杂系统一样，几乎可以肯定会发现错误，其中一些与安全相关。如果您发现安全漏洞，请私下报告给相关仓库的 MAINTAINERS 文件中列出的维护者，并抄送 [email protected]。我们将尽快修复该问题，并与您协调发布日期。您可以选择是否公开确认您的贡献以及是否提及您的姓名。
致安全扫描器用户特别提示：请谨慎对待扫描报告。大多数扫描器是通用型的，会产生大量误报。我们收到的报告越来越多，处理并回复所有报告需要大量工作，无法给予您期望的周全。Go 和 NPM 依赖项扫描器的误报问题尤为严重。
为了节省我们的时间和精力，我们恳请您不要提交原始报告。请代之以提交一份分析报告，说明哪些具体结果适用于我们以及原因。
Prometheus 由志愿者维护，而非公司。因此，安全问题的修复工作是尽力而为的。我们努力在 7 天内为以下组件发布安全修复：Prometheus、Alertmanager、Node Exporter、Blackbox Exporter 和 Pushgateway。
假定不受信任的用户可以访问 Prometheus 的 HTTP 端点和日志。他们可以访问数据库中包含的所有时间序列信息，以及各种运维/调试信息。
同时假定只有受信任的用户才能修改 Prometheus 及其他组件的命令行参数、配置文件、规则文件以及运行时环境的其他方面。
Prometheus 抓取哪些目标、频率如何以及使用哪些其他设置完全由配置文件决定。管理员可以选择使用来自服务发现系统的信息，这与重标记 (relabeling) 结合使用时，可能会将部分控制权授予任何能够修改该服务发现系统中数据的人员。
抓取的目标可能由不受信任的用户运行。默认情况下，目标不应能够暴露伪装成其他目标的数据。honor_labels 选项会移除此保护，某些重标记设置也可能如此。
从 Prometheus 2.0 版本开始，--web.enable-admin-api 标志控制对管理 HTTP API 的访问，该 API 包括删除时间序列等功能。此功能默认禁用。如果启用，管理和修改功能将可在 /api/*/admin/ 路径下访问。--web.enable-lifecycle 标志控制 Prometheus 的 HTTP 重载和关闭。此功能也默认禁用。如果启用，它们将在 /-/reload 和 /-/quit 路径下访问。
在 Prometheus 1.x 版本中，任何能够访问 HTTP API 的用户都可以访问 /-/reload 以及对 /api/v1/series 使用 DELETE 方法。/-/quit 端点默认禁用，但可以通过 -web.enable-remote-shutdown 标志启用。
远程读取功能允许任何拥有 HTTP 访问权限的用户向远程读取端点发送查询。例如，如果 PromQL 查询最终直接针对关系型数据库运行，那么任何能够向 Prometheus 发送查询（例如通过 Grafana）的用户都可以在该数据库上运行任意 SQL。
任何能够访问 Alertmanager HTTP 端点的用户都可以访问其数据。他们可以创建和解决告警。他们可以创建、修改和删除静默。
通知发送到哪里由配置文件决定。在某些模板设置下，通知可能会发送到告警定义的目的地。例如，如果通知使用告警标签作为目标电子邮件地址，那么任何可以向 Alertmanager 发送告警的人都可以向任何电子邮件地址发送通知。如果告警定义的目标是可模板化的秘密字段，那么任何能够访问 Prometheus 或 Alertmanager 的人都可以查看这些秘密信息。
任何可模板化的秘密字段旨在用于上述用例中的通知路由。它们并非旨在作为一种利用模板文件功能将秘密信息从配置文件中分离出来的方式。存储在模板文件中的任何秘密信息可能被任何能够在 Alertmanager 配置文件中配置接收器的人员窃取。例如，在大型设置中，每个团队可能拥有一个他们完全控制的 Alertmanager 配置文件片段，然后将这些片段合并成完整的最终配置文件。
任何能够访问 Pushgateway HTTP 端点的用户都可以创建、修改和删除其中包含的指标。由于 Pushgateway 通常在启用 honor_labels 的情况下被抓取，这意味着任何能够访问 Pushgateway 的人都可以 Prometheus 中创建任何时间序列。
--web.enable-admin-api 标志控制对管理 HTTP API 的访问，该 API 包括清除所有现有指标组等功能。此功能默认禁用。如果启用，管理功能将在 /api/*/admin/ 路径下访问。
Exporter 通常只与一个配置好的实例通信，使用一组预设的命令/请求，这些命令/请求无法通过其 HTTP 端点进行扩展。
还有一些 Exporter，例如 SNMP 和 Blackbox Exporter，它们从 URL 参数获取目标。因此，任何能够访问这些 Exporter 的 HTTP 端点的人都可以使它们向任意端点发送请求。由于它们还支持客户端认证，这可能导致秘密信息泄露，例如 HTTP 基本认证密码或 SNMP community 字符串。挑战-响应认证机制（例如 TLS）不受此影响。
客户端库旨在包含在用户的应用程序中。
如果使用客户端库提供的 HTTP 处理程序，恶意请求在到达该处理程序后，不应引起超出额外负载和抓取失败之外的问题。
Prometheus 和大多数 Exporter 都支持 TLS，包括通过 TLS 客户端证书对客户端进行认证。Prometheus 的配置详情在此处。
Go 项目共享基于 Go crypto/tls 库的同一 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 验证。
由于管理和修改端点旨在通过 cURL 等简单工具访问，因此没有内置的 CSRF (跨站请求伪造) 防护，因为这会破坏此类用例。因此，在使用反向代理时，您可能希望阻止此类路径以防止 CSRF。
对于非修改端点，您可能希望在反向代理中设置 CORS (跨域资源共享) 头信息，例如 Access-Control-Allow-Origin，以防止 XSS (跨站脚本攻击)。
如果您正在构建包含来自不受信任用户输入的 PromQL 查询（例如控制台模板的 URL 参数，或您自己构建的内容），而这些用户不应能够运行任意 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、RAM、磁盘空间、IOPS、文件描述符和带宽。
建议监控所有组件是否出现故障，并在故障发生时自动重启它们。
本文档考虑的是使用原始源代码构建的标准二进制文件。如果您修改了 Prometheus 源代码，或在您自己的代码中使用了 Prometheus 内部功能（超出官方客户端库 API），此处提供的信息不适用。
Prometheus 的构建管道运行在第三方提供商上，许多 Prometheus 开发团队成员和这些提供商的员工都可以访问这些平台。如果您对二进制文件的确切来源有所顾虑，建议您自行构建，而不是依赖项目提供的预构建二进制文件。
Prometheus-Community 组织下的仓库由第三方维护者支持。
如果您在 Prometheus-Community 组织中发现安全漏洞，请私下报告给相关仓库的 MAINTAINERS 文件中列出的维护者，并抄送 [email protected]。
该组织下的某些仓库可能具有与本文档中描述不同的安全模型。在这种情况下，请参考这些仓库的文档。
2018 年，CNCF 赞助了由 cure53 进行的外部安全审计，审计时间从 2018 年 4 月持续到 2018 年 6 月。更多详情，请阅读审计的最终报告。
2020 年，CNCF 赞助了由 cure53 对 Node Exporter 进行的第二次审计。
2023 年，CNCF 赞助了由 Chainguard 对 Prometheus 进行的软件供应链安全评估。
本文档是开源的。请通过提交 issue 或 pull request 帮助改进它。