Prometheus是一个复杂的系统，具有许多组件和许多与其他系统的集成。 它可以部署在各种受信任和不受信任的环境中。
本页介绍了Prometheus的一般安全假设以及某些配置可能启用的攻击向量。
与任何复杂的系统一样，不可能保证没有错误。 如果您发现安全漏洞，请私自向相关存储库的MAINTAINERS.md和CC [email protected]中列出的维护人员报告。 我们将解决问题并与您协调发布日期，确认您的努力，如果您愿意，请提及您的姓名
假定不受信任的用户可以访问Prometheus HTTP端点和日志。他们可以访问数据库中包含的所有时间序列信息，以及各种操作/调试信息。
还假设只有受信任的用户才能更改命令行，配置文件，规则文件以及Prometheus和其他组件的运行时环境的其他方面。
其中针对Prometheus的擦除，频率以及完全通过配置文件确定的其他设置。管理员可以决定使用来自服务发现系统的信息，其与重新标记相结合可以向可以修改该服务发现系统中的数据的任何人授予一些控制权。
被扫描的目标可能由不受信任的用户运行。默认情况下，目标不应该公开冒充不同目标的数据。 honor_labels选项会删除此保护，某些重新标记设置也会如此。
从Prometheus 2.0开始， --web.enable-admin-api标志控制对管理HTTP API的访问，其中包括删除时间序列等功能。默认情况下禁用此功能。如果启用，则可以在/api/*/admin/ paths下访问管理和变异功能。 --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中创建任何时间序列。
Exporters通常只与具有预设命令/请求集的一个已配置实例通信，这些命令/请求无法通过其HTTP端点进行扩展。
还有一些导出程序，例如SNMP和Blackbox导出程序，它们从URL参数中获取目标。 因此，对这些导出器具有HTTP访问权限的任何人都可以使它们向任意端点发送请求。 由于它们还支持客户端身份验证，因此可能会导致HTTP基本身份验证密码或SNMP社区字符串等机密泄露。 挑战 - 响应认证机制（如TLS）不受此影响。
客户端库旨在包含在用户的应用程序中。
如果使用客户端库提供的HTTP处理程序，则到达该处理程序的恶意请求不应该导致超出由额外加载和失败的擦除导致的问题。
Prometheus及其组件不提供任何服务器端身份验证，授权或加密。如果需要，建议使用反向代理。
由于管理和变异端点旨在通过简单的工具（如cURL）进行访问，因此没有内置的CSRF保护，因为这会破坏此类用例。因此，在使用反向代理时，您可能希望阻止此类路径以防止CSRF。
对于非变异端点，您可能希望在反向代理中设置CORS标头（如Access-Control-Allow-Origin）以防止XSS。
如果您正在编写PromQL查询，其中包含来自不受信任的用户的输入（例如，参数控制台模板的URL参数，或者您自己构建的内容），这些查询并不意味着能够运行任意PromQL查询，请确保适当地转义任何不受信任的输入以防止注入攻击。例如，如果<user_input>是""} or some_metric {zzz ="，则up{job="<user_input>""}将变为{job=""} or some_metric {zzz =""}。
对于那些使用Grafana注意，仪表板权限不是数据源权限，因此不要限制用户在代理模式下运行任意查询的能力。
各种Prometheus组件支持客户端身份验证和加密。如果提供TLS客户端支持，通常还会有一个名为insecure_skip_verify的选项，它会跳过SSL验证。
可以通过HTTP API和/或日志获得非机密信息或字段。
在Prometheus中，从服务发现中检索的元数据不被视为机密。 在整个普罗米修斯系统中，指标不被视为机密。
包含配置文件中的秘密的字段（在文档中明确标记）将不会在日志中或通过HTTP API公开。 不应将秘密放在其他配置字段中，因为组件通过其HTTP端点公开其配置是很常见的。
依赖项使用的其他来源的秘密（例如，EC2服务发现使用的AWS_SECRET_KEY环境变量）可能由于我们无法控制的代码或由于在任何存储位置发生的功能而最终暴露。
对于超额负载或昂贵的查询，存在一些缓解措施。 但是，如果提供的查询/指标太多或太昂贵，则组件将会崩溃。 更可能是受信任的用户意外取出组件而不是恶意行为。
用户有责任确保为组件提供足够的资源，包括CPU，RAM，磁盘空间，IOPS，文件描述符和带宽。
建议监视所有组件的故障，并在故障时自动重启。
本文档考虑了从库存源代码构建的vanilla二进制文件。 如果您修改Prometheus源代码，或在您自己的代码中使用Prometheus内部（在官方客户端库API之外），则此处提供的信息不适用。
Prometheus的构建管道运行在第三方提供程序上，Prometheus开发团队的许多成员和这些提供程序的工作人员都可以访问这些提供程序。 如果您担心二进制文件的确切来源，建议您自己构建它们，而不是依赖项目提供的预构建二进制文件。
CNCF在2018年4月至2018年6月期间通过cure53赞助了一项外部安全审计。
有关详细信息，请阅读审计的最终报告。