Skip to content
KubernetesObservabilityMulti-tenancy

Your tenant’s metrics should stay your tenant’s metrics

Md. Tawfiqul Bari
3 min read · Last reviewed November 1, 2026

Two tenants can both have a namespace called production. If a metrics query uses that name as its only boundary, it has not established whose production it is looking at.

That small example captures a larger problem with shared observability: the charts can look perfectly ordinary while the query underneath has access to too much data.

Derive the scope from identity

The server needs to determine which resources the caller owns and apply that scope to every read. A tenant name or cluster name supplied in a request is not sufficient authority.

Moncho derives query scope from the authenticated caller’s clusters and uses a globally unique telemetry identifier. A caller with no permitted clusters receives no matching data. An empty access list must never become an unrestricted query.

Constrain the query surface

Moncho exposes a fixed catalog of metrics and time ranges through the portal. Tenants can choose supported views, but they cannot submit raw metric or log query expressions.

That makes the authorization problem smaller. The server owns the query templates and applies the tenant scope; values such as a namespace or search term are escaped as literals. A search box should search for the text entered, not turn it into another query operator.

There is a trade-off. A fixed catalog does not offer the flexibility of an unrestricted query console. The supported views need to cover the questions operators actually ask, and the catalog needs maintenance as workloads change.

Make the scoped views useful

A cluster-wide memory chart may tell you there is a problem without helping you find it. Operators need to drill into their namespaces and workloads, inspect logs, and distinguish their applications from platform components.

Moncho provides those views inside the portal, alongside tenant-scoped service-level objectives and alerts. It does not embed a shared dashboard with a raw query surface for tenants.

Missing telemetry needs its own state, too. If the metrics store is unavailable, an empty response is not evidence that the cluster is healthy. Retention and storage durability should be assessed separately from access control: keeping a record private does not tell you how long it will remain available.

Test what a tenant must not see

A useful evaluation uses two test tenants with similarly named resources. Confirm each can inspect its own workloads, then try changing the requested namespace, resource identifier, and search text.

  • Does an unknown metric get rejected?
  • Does an account with no clusters receive no data?
  • Do log views enforce the same boundary as metrics?
  • Does an upstream outage appear as unavailable telemetry?

These checks do not replace a security review, but they make the intended boundary observable. For Moncho, that boundary is enforced in the server-side query path, where it can govern every supported view.

Written by

Md. Tawfiqul Bari

Md. Tawfiqul Bari

Founder & CEO, Vigilus Labs Incorporated

Md. Tawfiqul Bari is the founder and CEO of Vigilus Labs Incorporated, with a career spanning cybersecurity, cloud infrastructure, and enterprise security.

LinkedIn profile

If this maps to a system you run, the fastest next step is a 30-minute technical call: bring your engines, versions, and audit configuration, and we will run against a scenario you recognise. There is more on Moncho: managed Kubernetes if you would rather read first.

Your next step

See it against your own database estate.

Talk with an engineer. See the product against a scenario that matters to your team.

Request a technical demo

A conversation with the people building the product.