安全性
Prometheus 是一个复杂的系统，包含了许多组件和与其他系统的集成，它可以在各种受信或不受信的环境中部署。
此页面描述了 Prometheus 的一般安全性假设以及某些配置可能引致的攻击方式。
与任何复杂系统一样，你可能会发现 Prometheus 的一些安全相关漏洞。如果你发现了 安全漏洞 请将其私下报告给相关仓库的维护者，并抄送给 prometheus-team@googlegroups.com。我们会尽快修复问题，并与你协调发布日期。你可以选择是否公开你的贡献和努力，以及是否希望在其中提及你的名字。
自动化安全扫描器
对于安全扫描器用户：请留意生成的报告。大多数扫描器是通用的，会产生大量误报。目前，我们收到了越来越多的报告（特别是有关 Go 和 NPM 的依赖扫描器），我们需要大量工作来逐一审查并回复。
作为对我们以及我们时间的尊重，请不要提交原始报告。相反地，请提交其中特别适用于我们进行分析的某些特定结果及其发生的原因。
Prometheus 由志愿者维护，而非商业公司。因此，解决安全问题只能在尽力而为的基础上进行。我们力求在 7 天内为：Prometheus、Alertmanager、Node Exporter、Blackbox Exporter 和 Pushgateway 发布安全修复。
Prometheus
我们假定未受信任的用户可以访问 Prometheus HTTP 端点和日志，他们有权访问数据库中的所有时间序列信息，以及各种操作/调试信息。
同样我们也假定只有受信任的用户才有能力更改 Prometheus 及其他组件的命令行、配置文件、规则文件和其他运行时环境设置。
Prometheus 所抓取的 Target、频率和设置完全由配置文件确定。管理员可以结合 relabeling（重新标记），选择使用服务发现系统的信息，将一些控制权限授予给能够修改服务发现系统中数据的人。
抓取的 Target 可能由不受信任的用户运行。默认情况下，Target 不应暴露假冒一个不同 Target 的数据。然而，honor_labels选项会移除这种保护，某些 relabeling 设置也会导致这种情况。
从 Prometheus 2.0 开始，--web.enable-admin-api标志位控制访问管理 HTTP API 包括删除时间序列等功能。默认情况下这个功能是被禁用的。如果启用了，则用户可访问/api/*/admin/路径下的管理及修改功能。
在 Prometheus 1.x 中，/-/reload和通过DELETE对/api/v1/series的操作向任何具有 HTTP API 访问权限的人开放。/-/quit端点默认禁用，但可以通过-web.enable-remote-shutdown标志位启用。
Remote read 功能允许任何人通过 HTTP 访问 remote read 端点发送查询。例如，如果 PromQL 查询最终直接运行在关系数据库上，那么任何能够向 Prometheus 发送查询（如通过 Grafana）的人都可以针对该数据库执行任意 SQL。
Alertmanager
任何具有访问 Alertmanager HTTP 端点权限的用户都可以访问其数据。他们可以创建和解决（resolve）告警，同时也可以创建、修改和删除静默告警。
通知发送到何处由配置文件决定。通过某些模板设置，通知可能会发送到告警定义的目的地。例如，如果通知使用告警标签作为目的地电子邮件地址，任何可以向 Alertmanager 发送告警的人都可以将通知发送到任何电子邮件地址。如果告警定义的目的地是一个可模板化的秘文字段，具有访问 Prometheus 或 Alertmanager 权限的任何人都能看到这些秘密。
任何可模板的秘文字段都旨在用于在上述情况下路由通知。它们并非用于通过模板文件功能将秘文从配置文件中分离出来。存储在模板文件中的任何秘文都可能被能够配置接收器的 Alertmanager 配置文件的人窃取。例如，在大型设置中，每个团队可能拥有完全控制的告警管理器配置文件片段，然后组合成完整的最终配置文件。
Pushgateway
任何具有访问 Pushgateway HTTP 端点权限的用户都可以创建、修改和删除其中包含的指标。由于 Pushgateway 通常在启用 honor_labels 的情况下被抓取，这意味着任何具有访问 Pushgateway 权限的人都可以在 Prometheus 中创建任何时间序列。
--web.enable-admin-api 标志控制访问管理 HTTP API，包括擦除所有现有指标组的功能。默认情况下该功能是禁用的。如果启用，则可访问 /api/*/admin/ 路径下的管理功能。
Exporters
Exporter 通常通过预设的一组命令/请求，与一个配置实例通信。这一特点无法通过其 HTTP 端点扩展。
也有一些 Exporter，如 SNMP 和 Blackbox exporters 会从 URL 参数获取目标。因此，具有这些 Exporters 的 HTTP 访问权限的任何人都可以使它们发送针对任意端点的请求。由于它们也支持客户端侧的身份验证，这可能导致 HTTP Basic Auth 密码或 SNMP 社区字符串（SNMP community strings）等密钥的泄露。Challenge-response 身份验证机制（如 TLS）不受此影响。
客户端库
客户端库在设计上是被包含在用户的应用程序中的。
如果使用由客户端库提供的 HTTP handler，恶意请求到达该 handler 时，除了会导致额外负载和失败抓取外，不应导致其他问题出现。
认证、授权和加密
Prometheus 和大多数 Exporter 支持 TLS。有关配置 Prometheus 的详细信息，请参阅这里。
Prometheus 的 Go 项目基于 Go 的 crypto/tls 库共享相同的 TLS 库。我们默认使用 TLS 1.2 作为最低版本。这样的做法基于 Qualys SSL Labs 的建议，力求在默认配置和正确提供的证书下实现 A 级（grade ‘A’）安全性，同时尽可能接近上游 Go 默认设置，以在完美安全性和易用性之间取得平衡。
未来将为 Java Exporter 添加 TLS 支持。
如果你有特殊的 TLS 需求，如不同的密钥套件或较旧的 TLS 版本，你可以调整最低 TLS 版本和密钥套件，只要该密钥套件不在 crypto/tls 库中被标记为不安全即可。如果这仍然不适合你的场景，Prometheus 当前的 TLS 设置可以让你构建一个安全隧道，从而连接到具有更多特殊要求的服务器和反向代理。
HTTP Basic Auth 也被支持。Basic Auth 可以在没有 TLS 的情况下使用，但用户名和密码时会以明文形式在网络上传输。
在服务器端，Basic Auth 密码使用 bcrypt 算法存储为哈希值，请确保你选择的哈希轮数符合你的安全标准。更多的轮数使暴力破解更复杂，但会消耗更多的 CPU 资源和认证请求的时间。
Prometheus 的各个组件支持客户端身份验证和加密。如果组件支持 TLS 客户端，通常还有可以跳过 SSL 验证的名为 insecure_skip_verify 的选项。
API 安全性
管理性和修改性端点被设计为能够被简单工具（例如 cURL）访问，它们没有内置的 CSRF（跨站请求伪造）保护，因为这将会使得这类用例不可用。因此，在使用反向代理时，你可能希望阻止这些路径，以防止 CSRF。
对于非修改性端点，你可能希望设置 CORS（跨域资源共享）头，比如你的反向代理中的 Access-Control-Allow-Origin，以防止 XSS（跨站脚本）。
如果你正在组成包含来自不可信用户输入的 PromQL 查询（例如，通过控制台模板的 URL 参数，或你自己构建的内容），这些用户不应该能够运行任意 PromQL 查询，以确保任何不可信输入都能够被适当转义，防止注入攻击。例如，up{job="<user_input>"} 将解析为 up{job=""} or some_metric{zzz=""}，如果 <user_input> 是 "} or some_metric{zzz="。
对于使用 Grafana 的人，请注意仪表盘权限并不是数据源权限，因此不要限制用户在代理模式下执行任意查询。
密钥
非密钥信息或字段可能通过 HTTP API 和/或日志获取。
在 Prometheus 中，从服务发现检索的元数据不被视为密钥。在整个 Prometheus 系统中，指标不应被视为敏感信息。
在配置文件中包含密钥的字段（在文档中明确标记为如此）不会在日志或通过 HTTP API 中暴露。密钥不应放置在其他配置字段中，因为组件通常通过 HTTP 端点暴露其配置。用户要做的事是保护磁盘上的文件免受未经授权的读写。
来自依赖项（例如，作为 EC2 服务发现使用的 AWS_SECRET_KEY 环境变量）中密钥可能会因不受我们控制的代码或意外暴露其存储位置的功能而最终被泄露。
拒绝服务（Denial of Service）
Prometheus 已经设置了一些缓解措施来应对过载或昂贵查询的情况。
然而，如果提供的组件过多或过于昂贵，它们仍然可能会出现故障。当然，这更有可能是受信任用户无意间导致组件故障，而非恶意行为。
用户的责任在于确保他们为组件提供足够的 CPU、RAM、磁盘空间、IOPS、文件描述符和带宽。
我们建议监控所有组件以检测故障，并在故障时自动重启它们。
库
本文档考虑的是从标准源代码构建的原生二进制文件。如果你修改了 Prometheus 的源代码或在自定义代码中使用 Prometheus 内部 API（超出官方客户端库API之外），那么本文的信息不适用于你。
构建过程
Prometheus 的构建流程在第三方提供商上运行，这些提供商的许多成员以及提供商员工拥有访问权限。如果你担心自己二进制文件的具体来源，我们推荐你自行构建而不是使用依赖项目提供的预构建二进制文件。
Prometheus-社区
Prometheus-Community 组织下的仓库由第三方维护者支持。
如果你在 Prometheus-Community 组织中发现 安全漏洞 ，请私密地向相关仓库的维护者报告，并抄送 prometheus-team@googlegroups.com。
Prometheus-Community 组织下的某些仓库可能有和本文档中展示的不一样的安全模型。在这种情况下，请参阅这些仓库的文档。
外部审计
- 2018年，CNCF 赞助了由 cure53 进行的外部安全审计，该审计从2018年4月持续至6月。更多信息，请阅读审计报告。
- 2020年，CNCF 赞助了 cure53 对 Node Exporter 进行的第二次审计。
- 2023年，CNCF 赞助了 Chainguard 对 Prometheus 的软件供应链安全评估。
该文档基于 Prometheus 官方文档翻译而成。