Description
Proposal
In multi-tenant Prometheus setups (e.g with https://github.com/prometheus-community/prom-label-proxy) - particularly in IoT or edge environments - exposing the /api/v1/metadata endpoint can pose a security concern. Currently, the endpoint only supports filtering by metric names, as noted in the official documentation:
https://prometheus.io/docs/prometheus/latest/querying/api/#querying-metric-metadata
This means the endpoint returns metadata for all metrics known to Prometheus, regardless of origin. In environments where tenants share a Prometheus instance or where metrics are federated from multiple sources, this can unintentionally leak metric names and metadata across tenant boundaries.
Why this matters
In a multi-tenant environment, restricting API access to tenant-specific data is essential. Unlike endpoints such as /api/v1/query or /api/v1/series, the /api/v1/metadata endpoint cannot currently be scoped using label matchers, which makes it incompatible with secure tenancy enforcement mechanisms that rely on label-based access control.
Workarounds considered
A possible workaround involves:
- Fetching relevant metric names using
/api/v1/serieswith appropriate label matchers. - Filtering the full
/api/v1/metadata5419 response proxy-side/client-side.
However, this approach is inefficient and brittle, particularly at scale.
Proposed enhancement
Introduce support for label-based filtering to the /api/v1/metadata endpoint, similar to other query endpoints. For example:
GET /api/v1/metadata?match[]={tenant="foo"}
This would allow more secure and scoped access to metric metadata, making a step towards multi-tenancy enablement.
Thanks for considering this enhancement.