prometheus原生不支持ldap/oauth2认证，需通过oauth2-proxy或microsoft entra授权proxy等反向代理前置实现零信任架构，由其承担身份核验、mfa强制、组权限控制及tls全链路加密，prometheus专注采集与存储。
直接在 Prometheus 本身加认证不现实，它原生不支持 LDAP/OAuth2 登录、RBAC 或会话管理。要对接零信任架构（ZTA），核心思路是：把认证和授权逻辑前置到反向代理层，让 Prometheus 专注采集与存储，由外部 Auth Proxy 承担身份核验、令牌校验、最小权限路由等 ZTA 关键能力。
选型与部署 Auth Proxy
推荐使用 oauth2-proxy 或 Microsoft Entra 授权 Proxy（适用于 Azure 环境），二者均支持 OIDC、LDAP、GitHub、Azure AD 等主流身份源，并可集成企业级策略引擎（如 Open Policy Agent）。关键点：
- oauth2-proxy v7.4+ 支持 session 持久化、group-based 授权、header 透传（如 X-Forwarded-User/X-Forwarded-Groups）
- Entra 授权 Proxy 已进入维护期，但若环境已深度集成 Microsoft Entra ID，仍可稳定用于验证 Prometheus UI 和 API 请求
- Proxy 必须部署在 Prometheus 前端（如 Ingress Controller 后、Service 前），所有流量强制经其鉴权
配置零信任策略规则
ZTA 不是“登录一次就畅通无阻”，而是持续验证。需在 Auth Proxy 中定义细粒度策略：
- 限制访问源 IP 段（如仅允许企业办公网段或 ZTNA 客户端出口 IP）
- 要求 MFA 强制开启（oauth2-proxy 支持 prompt=select_account&access_type=offline 配合 Google/Azure AD）
- 按用户所属 LDAP 组控制路径权限：例如 /api/v1/query 允许 monitoring-readers，/api/v1/admin/tsdb 仅限 monitoring-admins
- 启用请求头签名验证（如检查 X-Forwarded-Client-Cert 或自定义 JWT claim）确保链路未被中间人篡改
与 Prometheus Operator 协同配置
若使用 Prometheus Operator（v0.60+），需同步调整 CRD 资源以适配代理后置架构：
- 在 Prometheus CR 中关闭内置 Basic Auth（避免冲突），禁用
--web.enable-admin-api - 通过 Ingress 暴露服务时，在 annotation 中指定 auth-url、auth-signin，并挂载 proxy 的 service 名称（如 nginx.ingress.kubernetes.io/auth-url: "https://auth-proxy.default.svc.cluster.local/oauth2/auth"）
- 将 Alertmanager 的 Web 地址也统一走同一 Auth Proxy，保持策略一致性；其 webhook 回调地址需配置为内部 ClusterIP，避免绕过代理
- Remote Write/Read 若需带身份上下文（如写入 Azure Monitor），应使用 OAuth2 字段注入 token，而非依赖 Proxy 的 header —— 二者职责分离：Proxy 管用户访问，remote 配置管系统间通信
证书与 TLS 全链路加固
ZTA 要求所有通信加密且可信。必须完成以下三项：
- 为 Auth Proxy 配置企业 PKI 签发的 TLS 证书（非自签），并设置
cookie_secure=true、cookie_httponly=true - 让 Prometheus 与 Exporter 之间启用 HTTPS 抓取：在 ServiceMonitor 或 PodMonitor 中配置
tlsConfig，引用包含 CA bundle 的 Secret - 若使用 Remote Write 到受信后端（如 Thanos Sidecar 或 Azure Monitor），在 Prometheus CR 的
remoteWrite.oauth2中明确指定 scope（如["monitor:write"]），并确保 tokenUrl 受企业 IdP 保护
