生产环境 prometheus 必须禁用 debug/pprof、启用 basic auth 认证、限制网络暴露面、分离权限并最小化暴露。需设置 --web.enable-debug=false，使用 bcrypt 加密密码的 web.yml 配置认证，仅通过 clusterip+ingress 或反向代理暴露，结合 networkpolicy 与多实例租户隔离实现安全管控。
生产环境中的 Prometheus 绝不能“裸奔”。默认安装后所有接口（/、/api/v1/*、/metrics、/debug/pprof/）全部无认证开放，相当于把系统运行状态、业务指标、甚至内存堆栈全摊在内网甚至公网。安全加固不是锦上添花，而是守住底线。
必须关闭 debug/pprof 接口
该接口是 Go 运行时调试工具，默认启用，会暴露协程堆栈、内存分配、CPU profile 等敏感信息。攻击者可借此分析服务结构、定位漏洞或发起 DoS。加固方式很简单：启动时显式禁用。
- 在 Prometheus 启动命令中添加参数：
--web.disable-exporters不够，真正有效的是--web.enable-admin-api=false --web.enable-lifecycle=false（防止配置热重载被滥用），但最关键的是--web.enable-debug=false - 若使用 systemd，确保
ExecStart行包含该参数；若用 Helm 或 kube-prometheus，需在prometheusSpec中设置enableAdminAPI: false和enableDebug: false - 验证是否生效：访问
http://<ip>:9090/debug/pprof/</ip>应返回 404 或 403
强制启用 Basic Auth 认证
这是最轻量、兼容性最好、且被 CNCF 多数企业采用的第一道防线。Prometheus 原生支持，无需额外组件。
- 密码必须用 bcrypt 加密（非 SHA 或 MD5），推荐
rounds=12。明文或弱哈希等于没设防 - 生成
web.yml配置文件，内容格式为：
admin: $2b$12$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
- 启动时通过
--web.config.file=/path/to/web.yml指定；注意该文件权限必须严格（如chmod 600 web.yml），避免被其他用户读取 - Grafana 若直连 Prometheus，需在数据源配置中填入对应用户名密码，否则查询会 401
限制网络暴露面
不靠“藏 IP”或“改端口”来安全，而要主动收缩访问通道。
- 禁止使用
NodePort或直接hostNetwork暴露 Prometheus；应仅用ClusterIP+ Ingress（K8s）或反向代理（裸机）统一入口 - Ingress 层可叠加 OAuth2（如 oauth2-proxy）实现统一登录，让 Prometheus、Alertmanager、Grafana 共享同一套认证，避免多套密码管理混乱
- 对内网访问也需设限：通过 Kubernetes
NetworkPolicy仅允许特定命名空间（如monitoring）或标签（如role=admin）的 Pod 访问 Prometheus Service
分离权限与最小化暴露
监控数据本身就有分级——运维看全量，开发可能只需查自己服务的指标。
- Prometheus 本身不支持 RBAC，但可通过 租户隔离+多实例 实现：为不同团队部署独立 Prometheus 实例，配合
serviceMonitorSelector（Operator 场景）或relabel_configs过滤目标 - Alertmanager 的 Web UI 允许静默告警，务必同样加认证；其 API 若被 Prometheus 调用，建议走内部 ClusterIP + TLS 双向认证，而非裸 HTTP
- 所有配置文件（
prometheus.yml、web.yml、alert.rules）应由 CI/CD 流水线注入，禁止手动上传或 shell 登录修改
