如何保护 Prometheus 指标端点的安全？

许多 exporter 的 /metrics 端点未配置认证；具体默认值取决于实现和部署，内网开放同样有风险（泄露内部架构、版本、业务数据）。加固从四层入手：网络隔离、传输加密、访问认证、最小暴露。

1. 网络层限制（最优先）

• 防火墙/安全组：只允许 Prometheus 服务器 IP 访问 9100/9090 等端口；
• K8s：在支持并执行 NetworkPolicy 的网络插件下，配置入口策略，只允许指定 monitoring 命名空间和 Pod 访问 metrics 端口；hostNetwork 和节点端口须另行验证；
• 绑定地址：能绑内网网卡就不要绑 0.0.0.0。

2. 端点侧加认证

反向代理（Nginx）统一鉴权：

location /metrics {
    allow 10.0.0.0/8;
    deny all;
    auth_basic "metrics";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:9100;
}

上述 location 应放在配置了 TLS 证书的 HTTPS server 中，并阻止绕过代理直连 exporter。Prometheus 抓取侧配置 scheme: https、basic_auth 和所需 CA；Basic Auth 本身不加密传输。

3. 传输加密

• exporter 前挂 HTTPS 代理，或用支持原生 TLS 的 exporter；
• Prometheus 自身的 Web 界面/API 用 web.config.file 开启 TLS 与 basic auth：

# web.config
tls_server_config:
  cert_file: /etc/prometheus/server.crt
  key_file: /etc/prometheus/server.key
basic_auth_users:
  admin: $2y$10$...(bcrypt 哈希)

启动 Prometheus 时指定 --web.config.file=/etc/prometheus/web.config，并挂载对应文件和证书。示例中的 bcrypt 哈希是占位值，须替换为真实生成值；抓取客户端使用实际密码或密码文件，不能把服务端哈希当作密码。

4. 最小暴露

• 指标里别放敏感值（查询参数、用户信息）——先过一遍 /metrics 输出自查；
• metric_relabel_configs 可在抓取后、入库前丢弃指标，但无法阻止敏感值先经端点和网络暴露；敏感数据应从 exporter 输出中移除。

如果由同机 DataKit 抓取，可在 prom 采集器中配置本机端点及所需 TLS、认证参数，并从采集器所在网络环境测试连接。只有采集器与应用共享相应网络空间时，绑定 localhost 才可行；容器和跨主机部署仍需单独限制访问来源。

常见问题（FAQ）

Q：Pushgateway 需要同样保护吗？ 需要，且它可写——可达且未设认证时，访问者能够推送假指标，网络隔离必须做。

Q：K8s 里 kubelet 的 10250 端口呢？ 同理敏感。10250 通常是节点上的 kubelet HTTPS 服务，不能假定 Pod NetworkPolicy 能保护它。应限制节点网络入口，关闭匿名认证、配置认证与授权并校验证书，再为采集账号授予必要权限；具体措施取决于集群配置。