/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 抓取哪些目标，抓取频率以及使用哪些其他设置完全由配置文件决定。管理员可以决定使用来自服务发现系统的信息，结合重新标记，这可能会将部分控制权授予任何可以修改该服务发现系统中的数据的人。
抓取目标可能由不受信任的用户运行。默认情况下，目标不应有可能暴露数据来冒充不同的目标。honor_labels 选项会移除此保护，某些重新标记设置也会如此。
从 Prometheus 2.0 开始，--web.enable-admin-api 标志控制对管理 HTTP 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/*/admin/ 路径下可访问。
Exporters 通常只与一个配置的实例通信，该实例具有预设的命令/请求集，这些命令/请求无法通过其 HTTP 端点扩展。
还有一些 exporters，例如 SNMP 和 Blackbox exporters，它们从 URL 参数中获取其目标。因此，任何有权访问这些 exporters 的 HTTP 的人都可以使它们向任意端点发送请求。由于它们还支持客户端身份验证，这可能会导致密钥泄漏，例如 HTTP 基本身份验证密码或 SNMP 团体字符串。TLS 等质询-响应身份验证机制不受此影响。
客户端库旨在包含在用户的应用程序中。
如果使用客户端库提供的 HTTP 处理程序，则到达该处理程序的恶意请求不应导致超出额外负载和抓取失败的问题。
Prometheus 和大多数 exporters 都支持 TLS。包括通过 TLS 客户端证书对客户端进行身份验证。有关配置 Prometheus 的详细信息，请参阅 here。
Go 项目共享相同的 TLS 库，该库基于 Go crypto/tls 库。我们默认使用 TLS 1.2 作为最低版本。我们关于此的政策基于 Qualys SSL Labs 建议，我们力求在默认配置和正确提供的证书下实现 'A' 级，同时尽可能接近上游 Go 默认值。达到该级别可以在完美的安全性和可用性之间取得平衡。
TLS 将在未来添加到 Java exporters 中。
如果您有特殊的 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、文件描述符和带宽。
建议监控所有组件的故障，并在故障时自动重启它们。
本文档考虑从库存源代码构建的 vanilla 二进制文件。如果您修改了 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 帮助改进它。