Proxy-based controls matter because a label filter alone does not prove the caller is entitled to see that tenant’s metrics. Without request authorization, a user could query data that belongs to another permissions system even if the query is syntactically valid. Checking the subject and object at request time closes that gap and limits exposure to only allowed data.
Why proxy-based controls are the enforcement point, not just a filter
When multiple permissions systems share one Prometheus deployment, the shared datastore becomes the hard part of the design. A label filter can narrow what a query looks like, but it does not by itself prove the requester is entitled to that tenant’s metrics. A proxy-based control evaluates the request before the data path is opened, which is why request-time enforcement matters when boundaries overlap.
That distinction is especially important when tenancy is enforced by convention rather than by physical separation. If the same Prometheus instance serves several groups, the query layer must decide not only whether the syntax is valid, but whether the subject making the request is allowed to see the object being queried. The control point therefore has to sit where identity, tenant context, and query execution meet.
A useful way to think about this is that the proxy becomes the policy decision and enforcement boundary. It can compare the caller, the target tenant, and the requested metric scope before the query reaches storage. For practitioners, that is the difference between “this query matches the label pattern” and “this caller is authorised to obtain these results.”
For background on why shared machine-access paths can become high-risk when privilege is broad or poorly tracked, NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks is a useful companion.
What breaks if you rely on labels alone
Label-based controls are useful for routing and scoping, but they are not an entitlement system. A valid label match can still expose another permissions system’s data if the request is not checked against the caller’s rights at runtime. In practice, the failure mode is simple: the query remains syntactically correct while the access decision is never made.
This matters because metrics platforms tend to accumulate shared operational assumptions. Teams may assume that “tenant” labels, dashboards, or query conventions are enough to prevent cross-system visibility. That assumption breaks as soon as the same deployment serves more than one permissions domain, because the data plane can no longer infer intent from structure alone.
- Label filters reduce the result set, but they do not establish authorisation.
- Request-time checks can enforce which subject may access which object, even when both live in one backend.
- Proxy placement helps centralise the policy decision instead of duplicating it across dashboards and ad hoc queries.
For a broader view of the over-privilege and visibility problems that show up when shared access paths are not tightly governed, see OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs, Why NHI Security Matters Now.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Shared Prometheus access depends on controlling who may use query credentials and tokens. |
| NHI-03 — Privilege Management | A proxy must enforce tenant-scoped privilege when one deployment serves multiple permissions systems. | |
| Recommendation — Bind query access to least-privilege credentials and rotate any shared access material promptly. Enforce tenant-scoped privileges at request time before any metric data is returned. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorization | The core issue is whether the requester is authorised for the requested metrics, not whether the query is valid. |
| Recommendation — Apply request-time authorisation checks before releasing shared Prometheus data. | ||
| CIS Controls v8 | 6.3 — Require Authentication for Enterprise Assets and Software | A shared metrics plane needs strong authentication so the proxy can make a trustworthy access decision. |
| 6.4 — Require Multi-Factor Authentication for Externally-Exposed Applications | If the proxy is exposed broadly, stronger authentication reduces the chance of unauthorised metric access. | |
| Recommendation — Require authenticated access before allowing any query into the shared monitoring path. Require MFA on exposed query entry points that front shared telemetry data. | ||
| NIST SP 800-63 | IAL/AAL/FAL — Digital Identity Assurance Levels | A proxy-based decision depends on trustworthy authentication and federation context for the caller. |
| Recommendation — Use the highest appropriate assurance level for identities that can query shared monitoring data. | ||
| MITRE ATT&CK | T1212 — Exploitation for Credential Access | If access control is weak, attackers can abuse shared monitoring paths to retrieve data they should not see. |
| Recommendation — Hunt for unauthorized query paths that could expose metrics after credential abuse. | ||
Practitioner Guidance
What to verify: Confirm that the proxy evaluates tenant membership or permissions at request time, not just query shape. If a user can change labels, route selection, or query parameters without an accompanying authorisation check, the control is not doing the real security work.
Decision rule: If one Prometheus deployment serves more than one permissions domain, treat the proxy as the enforcement point and make the downstream store non-authoritative for access decisions. That keeps the access decision attached to the caller and request, not to a reusable label convention.
What good looks like: A successful control lets the same metric backend remain operationally shared while each request is still bounded to the right tenant or permissions system. The observable sign is that a syntactically valid query can still be denied when the caller lacks entitlement.
Practitioner takeaway: Shared observability backends should be designed so that the data path can only return what the caller is entitled to see, because query validity and access entitlement are not the same control.
Related resources from NHI Mgmt Group
- Why do distributed ledger systems matter when multiple financial firms must reconcile the same transaction record?
- How should organisations implement policy-based access control when multiple business units share the same cloud data store?
- Why does recursive subject discovery matter for authorization systems that model access as a relationship graph?
- What is the impact of adding caveats to a permissions system for policy-based authorization?
