How should platform teams implement multi-tenant telemetry routing in Kubernetes without exposing one team’s logs to another?

Why This Matters for Security Teams

Multi-tenant telemetry routing sits at the intersection of observability and data isolation. In Kubernetes, logs, metrics, and traces often carry operational context that can reveal incident details, customer data, API payload fragments, or deployment metadata. If routing rules are too broad, one tenant can inherit visibility into another tenant’s telemetry by accident, which turns a convenience feature into a cross-team exposure problem.

That is why the routing model has to be designed around tenant boundaries, not around collector convenience. Cluster-level components should enforce the baseline policy, while team-level subscriptions should only narrow what a tenant can see and where it can send data. Containerised telemetry pipelines also need disciplined hardening because collectors, sidecars, and output plugins are part of the trust path, not just plumbing. Guidance such as NIST SP 800-190 Container Security is useful here because it frames the orchestrator and runtime as security-relevant components, not neutral infrastructure.

In practice, many teams discover telemetry leakage only after a noisy incident or support request has already exposed that the routing rules were shared too broadly.

How It Works in Practice

The cleanest pattern is to separate policy enforcement from tenant selection. A cluster-scoped collector sets the global guardrails, such as allowed destinations, default filtering, and which namespaces are eligible for export. Namespace-scoped subscriptions then let each team decide which logs, metrics, or traces from its own workloads should be forwarded, without allowing a tenant to expand its view outside its boundary.

Label selectors are the mechanism that makes this precise. Teams should label namespaces, workloads, or telemetry streams consistently, then bind subscriptions to those labels so the collector only routes the intended data. This avoids the common failure mode where a wildcard subscription or shared output sends everything to a central sink that every tenant can query. When possible, use separate outputs per tenant or per environment, and keep those outputs enforced by policy rather than by convention.

• Define tenant ownership at the namespace level before writing any routing rules.
• Use cluster-scoped collectors only for global constraints, not tenant-specific exemptions.
• Bind subscriptions to labels that are unique, reviewable, and hard to spoof.
• Isolate outputs so one team cannot read another team’s destination or back-end credentials.
• Test the effective routing path, not just the YAML, because admission and controller behaviour can differ.

Operationally, this works best when the telemetry pipeline is treated like any other multi-tenant control plane, with change review, least privilege, and explicit ownership. Teams should be able to create and adjust their own subscriptions within their namespace, but not alter shared collector policy or destination-level access. These controls tend to break down when namespaces are reused casually, labels are inconsistent, or the routing layer depends on manual review instead of enforceable selectors.

Common Variations and Edge Cases

Tighter telemetry isolation often increases routing complexity, so teams have to balance self-service against policy sprawl. The standard model is straightforward in a clean namespace-per-tenant design, but mixed environments, shared platform namespaces, and cross-cutting operational tooling create exceptions that need extra care.

One common edge case is centralised logging for security or compliance. In that model, tenants may still ship data to a shared platform sink, but they should not gain broad read access to the sink itself. Another is cross-namespace workloads, such as shared ingress, service meshes, or platform operators, where a single workload can emit telemetry on behalf of multiple tenants. In those cases, label-based routing must be paired with ownership rules so the platform team can distinguish producer identity from data ownership. There is no universal standard for every Kubernetes telemetry stack, so current guidance suggests validating the effective access model rather than assuming that a namespace boundary alone guarantees isolation.

Another variation arises when teams need both tenant-local observability and enterprise-wide correlation. The safer pattern is to duplicate only the necessary telemetry into separate destinations, rather than making one shared stream readable by all tenants. The moment a routing decision becomes reusable across tenants, it should be treated as a shared policy asset and reviewed accordingly.

Risk and Threat Considerations

Cross-tenant telemetry routing creates a confidentiality and governance risk because logs and traces frequently contain more than operational noise. They can expose request paths, identifiers, error payloads, and configuration clues that help an attacker or an over-privileged internal user learn too much about another team’s environment.

Failure mechanism: The risk materialises when routing is defined too broadly, when selectors are ambiguous, or when shared outputs provide a read path that was intended only for one tenant. In Kubernetes, the weak point is often not the collector itself but the combination of namespace reuse, broad subscription scope, and destination access that is easier to inherit than to audit.

Impact: One tenant can see another tenant’s telemetry, incident details can leak across teams, and sensitive operational data can end up in a shared backend without a clear ownership boundary. That creates both privacy exposure and a response problem, because investigators may be forced to unwind who could see what after the fact.

Practitioner Guidance

What to prioritise: Treat namespace ownership and output isolation as the first design decision, not an implementation detail. If those boundaries are unclear, routing rules will eventually reflect that ambiguity.

What to verify: Confirm that each subscription resolves only to the intended namespaces and streams, and test the actual effective access path to the destination store. A configuration that looks isolated can still leak if labels are reused or outputs are shared.

Decision rule: If a routing rule can be applied across tenants without a compensating access boundary, it should be considered too broad for production. Keep tenant choice local, keep export policy global, and require review for anything that crosses that line.

Practitioner takeaway: The goal is not just to move telemetry efficiently, it is to make leakage structurally hard by designing the route, the selector, and the destination around tenant boundaries from the start.

Related resources from NHI Mgmt Group

• How should security teams implement cross-cluster search for multi-tenant security monitoring without centralizing the underlying logs?
• How should teams implement RBAC in multi-tenant SaaS without creating access leakage?
• How should security teams govern multi-tenant telemetry without duplicating pipelines?
• How should security teams implement BYOK in multi-tenant SaaS without turning it into a major engineering project?