Prometheus默认无身份认证与权限控制，需通过反向代理（如Nginx）实现Basic Auth、IP白名单及本地绑定；对敏感label脱敏、禁用高风险API端点；启用代理层审计日志并关联告警，限制PromQL危险函数与Grafana直连。
Prometheus 本身不内置用户身份认证和细粒度权限控制，它的默认设计是“信任内网”，因此数据安全高度依赖外围加固。访问控制与审计不是可选功能，而是生产环境的底线要求——尤其当指标中包含主机名、服务端口、数据库连接串、业务路径等敏感标签时，一次未授权查询就可能暴露整个系统拓扑。
反向代理层实现基础访问控制
Prometheus Server 没有原生登录页或用户管理模块，最实用、最广泛采用的方式是前置 Nginx 或 Apache 做认证网关：
- 配置 Basic Auth，用
auth_basic和auth_basic_user_file限制所有 HTTP 请求入口 - 将 Prometheus 绑定到
127.0.0.1:9090，仅允许反向代理本地访问，彻底屏蔽公网直连 - 结合 IP 白名单（
allow/deny）进一步缩小可信来源范围，例如只允运维跳板机或 Grafana 所在节点访问
标签级数据脱敏：从源头降低泄露危害
很多敏感信息并不来自密码字段，而是藏在 Prometheus 的 label 中——比如 instance="db-prod-01.internal:5432"、job="payment-service"、甚至 path="/api/v1/users?token=xxx"。这些 label 会随指标一并暴露在 API 查询结果里：
- 在采集配置中使用
relabel_configs删除或哈希化高风险 label（如__address__、instance、url） - 对 exporter 输出的原始指标做预处理，避免将真实主机名、路径、参数直接打标
- 禁用
/api/v1/series和/federate端点（除非强需求），它们极易被用于枚举全部时间序列和 label 组合
启用审计日志并关联告警行为
Prometheus 自身不记录谁在什么时候查了什么，但可通过以下方式补足审计能力：
- 在反向代理层开启 access log，记录请求路径、IP、响应状态、User-Agent（含 Grafana 或 curl 等调用来源）
- 将日志接入 SIEM（如 ELK 或 Loki），设置规则识别高频查询、异常时间窗口访问、或针对
password、secret、token等关键词的 PromQL 查询 - 配合 Alertmanager 的 webhook，对可疑查询行为触发内部通知（例如非工作时间连续 5 次失败认证后出现成功访问）
限制 API 能力与查询范围
并非所有 Prometheus API 都需要开放给所有人：
- 关闭
/status、/config、/flags等调试端点，它们会泄露配置细节、启动参数、甚至远程写入地址 - 通过反向代理重写或拦截，禁止执行含危险函数的 PromQL（如
label_values()、metrics()、正则匹配任意 label 的{__name__=~".*"}） - 对 Grafana 数据源配置启用
access: proxy（而非direct），确保所有查询经由后端代理转发，便于统一鉴权和限流
