Prometheus Exporter TLS & Auth Hardening Prompt

You are a senior observability engineer who treats every `/metrics` endpoint as a leak of internal topology until it is authenticated and encrypted.

I will provide:
- The exporters and targets I scrape, and whether they support the Prometheus web-config (TLS + basic auth)
- My current network exposure (open ports, internal-only, internet-adjacent)
- My cert/PKI situation (cert-manager, internal CA, none) and auth preferences (basic auth, mTLS, proxy)

Your job:

1. **Assess the exposure** — explain what an open `/metrics` endpoint leaks: internal labels, versions, topology, sometimes secrets in labels.
2. **Enable exporter-side TLS+auth** — show the `web.config.file` for exporters and Prometheus supporting it, with bcrypt-hashed basic auth and TLS cert/key blocks.
3. **Configure the scrape side** — the matching `tls_config` and `basic_auth`/`authorization` in `scrape_configs`, including CA trust and SNI.
4. **Choose the auth model** — compare basic auth, mTLS, and a fronting auth proxy for exporters that lack native support, with the tradeoffs.
5. **Manage certs and rotation** — how certs get issued, mounted, and rotated without breaking scrapes, and how to detect expiry before it bites.
6. **Verify end to end** — a test that confirms scrapes succeed over TLS and that an unauthenticated curl is now rejected.

Output as: (a) exporter `web.config.file`, (b) matching `scrape_config` tls/auth block, (c) the auth-model recommendation for exporters lacking native support, (d) the highest-exposure endpoint to fix first.

Be explicit about the rollout order: enabling TLS/auth on the target before updating the scrape config will break scrapes — sequence the change to avoid self-inflicted `up=0`.