本篇是《Prometheus 从入门到生产实践》第 15 / 24 篇。配置以文中版本与环境前提为准，实验和故障均为教学场景。完整程序、配置及校验范围见配套实验包。
监控数据里可能有主机地址、业务结构、部署信息和容量情况。Prometheus 还提供昂贵查询与管理入口，所以“只是一个看图页面”并不能说明它适合直接开放公网。本篇从实际访问路径建立保护，而不是简单给页面加一层密码就结束。
1. 先区分四条连接
| 连接 | 需要确认的对象 |
|---|---|
| 用户、Grafana → Prometheus | Web TLS、身份、可访问 API 范围与查询资源 |
| Prometheus → exporter | 目标证书、采集身份、超时与网络范围 |
| Prometheus → Alertmanager | 通知链路的身份、地址和信任 |
| Alertmanager → 接收端 | webhook、邮箱或机器人凭据、接收方验证 |
某一侧配置 TLS，不会自动保护另外三侧。Prometheus 的安全模型假定能访问其 HTTP 端点的用户处于相应信任范围，不能把原生界面当成具备细粒度业务授权的多租户平台。整体假设见 官方安全模型。
2. 为独立实验 Web 入口启用 HTTPS
下面的 b-web.template.yml 是模板，必须先准备证书、私钥和密码哈希，不能把占位符直接投入运行：
# Template only: provide trusted certificate/key files and a generated bcrypt hash.
tls_server_config:
cert_file: ./certs/server.crt
key_file: ./certs/server.key
min_version: TLS12
basic_auth_users:
ops: '<REPLACE_WITH_BCRYPT_HASH>'
证书的 SAN 应包含客户端实际请求的域名或地址，证书链必须被客户端信任。只把 CN 写成某个名字，不保证现代客户端会按预期接受它。
在已有 htpasswd 工具的 Linux 测试环境，可交互生成 bcrypt 条目：
htpasswd -nBC 12 ops
把冒号后面的哈希放入模板的单引号中，保存为 b-web.yml。不要把明文密码直接写进 YAML，也不要复用公开教程中已知密码对应的哈希。basic_auth_users 的密码格式和 TLS 配置见 HTTPS 与认证文档。
把账户名叫 viewer 或 readonly，也不等于具有“只读角色”：原生 Basic Auth 主要验证身份，不会自动给不同用户建立按 job、标签或端点划分的授权策略。
3. 在新数据目录验证，不改正在使用的实例
证书与哈希填好后，可使用相同采集配置启动独立测试 Web 入口：
prometheus --config.file=prometheus.yml \
--web.config.file=b-web.yml \
--web.listen-address=127.0.0.1:19091 \
--storage.tsdb.path=./tls-data
它使用独立端口和 TSDB，不与主实验 19090 共用数据目录。这里只验证 Web 安全；采集目标仍按 prometheus.yml 配置执行。
使用可信的 CA 文件验证：
curl --cacert ./certs/ca.crt -u ops \
https://localhost:19091/-/ready
-u ops 让 curl 提示输入密码。根据实际证书替换 CA 和域名。预期正确身份及证书可得到 ready；没有认证应被拒绝，域名错误或不信任证书也应失败。不要把 -k 成功作为 TLS 正确的验收标准。
若改造的是 Prometheus 自己的采集端点，自采集也需要匹配新的 scheme、信任与认证配置；不能假设来自本机的请求会自动绕过密码。
4. 采集端认证和 Web 用户认证不是同一配置
以下片段表示 Prometheus 作为客户端访问另一个受保护 exporter，地址和文件都需要替换：
# Merge this job into scrape_configs; referenced secret and CA files must exist.
scrape_configs:
- job_name: secure-demo
scheme: https
static_configs:
- targets: ['metrics.example.test:443']
authorization:
type: Bearer
credentials_file: /etc/prometheus/secrets/demo.token
tls_config:
ca_file: /etc/prometheus/certs/metrics-ca.crt
server_name: metrics.example.test
凭据文件只保存实际 token 内容，由 Prometheus 进程以受限文件权限读取。server_name 用于预期的服务名称，ca_file 提供信任链；这与让服务端关闭验证完全不同。
需要双向 TLS 时，再按实际 PKI 加入客户端证书与私钥。mTLS 可以确认对端证书身份，但应用仍需决定该身份被允许做什么。HTTP 客户端配置字段见 Prometheus 配置参考。
5. 管理 API、重载和查询成本分别限制
--web.enable-admin-api 控制包括删除时间序列在内的管理 API，默认关闭；--web.enable-lifecycle 控制 HTTP reload 和 quit，默认也关闭。这两个开关不是同一个权限。
如果有反向代理，只允许 UI 路径而意外透传所有 API，仍可能暴露敏感能力。应根据真实运维流程决定哪些访问入口可达，代理层认证后还要保护后端直连路径。
即使不开放管理 API，昂贵查询也会消耗 CPU、内存和存储读取。查询超时、并发和样本限制、网络准入以及可靠的访问日志应共同设计。禁止某个用户访问 UI，并不自动阻止它直接调用查询 API。
6. 指标和通知中也不能泄露凭据
不要把 token、邮箱地址、完整请求 URL 或用户标识放进标签。除了敏感信息风险，这些变化快的值也会制造高基数。
Alertmanager 的 webhook URL 若带凭据，同样需要受控管理。能使用当前集成支持的 *_file 配置时，优先从受限文件读取；不同通知集成支持的字段不同，按其版本核对，不能给所有字段随意加 _file 后缀。
Blackbox 等多目标 exporter 还需要限制谁能指定目标，否则它可能成为从监控网络发起任意探测的入口。网络侧允许的出口范围，是应用配置之外的另一层约束。
7. 身份、授权和网络分别回答一个问题
身份验证回答“对方是谁”，授权回答“这个身份可以做什么”，网络边界回答“请求能不能到达这里”。把这三件事混在一起，常会出现用户已经通过统一登录，却能直接查询所有环境的情况。
例如，反向代理只在首页检查登录，后面的查询接口没有同样约束，就不能称为完成了入口保护。即使代理路径都正确，后端端口仍被其他网络直接访问，也可能绕过代理。验收应从允许和不允许的来源分别发起请求，而不是只在管理员电脑上点开一次页面。
原生认证不能自动把不同团队的标签数据隔离。若需求是严格多租户，需要由适合该需求的网关、存储与查询架构实现一致的租户边界，并验证写入与查询两端，不应仅靠面板里隐藏一个变量。
8. 轮换与故障恢复要一起设计
文件方式管理凭据并不意味着已经没有风险。运行账户需要读文件，但不需要让所有本机用户读到私钥和令牌；备份和诊断打包也应避免把秘密带出去。证书中的公开内容和私钥不是同一种保密对象，不能因为证书可分发就把私钥权限一并放开。
轮换时先列出所有使用者：采集器、可视化系统、自动化查询、规则验证和通知服务可能分别持有旧凭据。按接收方支持的方式更新，观察新身份确实生效，再撤销旧身份。只修改发起端而接收端尚未信任新证书，可能把安全变更变成采集故障。
短期证书或临时令牌也需要到期前的监测与负责人。证书过期产生的抓取失败和目标服务宕机不同，但都应有可解释的告警及续期路径。发生故障时，优先恢复正确的信任或身份，不要长期保留跳过校验的临时开关。
对于诊断记录，保留状态码、服务名称、证书到期信息和错误类型通常已经足够。完整凭据、请求头和带秘密的地址不应成为每条调试日志的默认内容。
9. 验收时验证拒绝路径和轮换
至少检查正确凭据成功、无凭据拒绝、错误证书失败、禁用的管理操作不可达、后端不能绕过代理直连。再演练一次凭据轮换，确认采集和通知两端都更新，而不是只替换了磁盘文件。
本机实验无需对公网开放端口。生产接入时，将监听地址、边界代理、网络策略、身份来源与操作审计一起记录，才能让“谁能访问什么”成为可验证的事实。
上一篇：Alertmanager：路由、分组、静默、抑制与恢复通知 · 系列目录 · 下一篇：Kubernetes 原生采集：Pod、EndpointSlice 与最小 RBAC