Shared collection becomes risky because telemetry data is processed together unless the platform adds isolation. Without tenant-aware routing, users cannot reliably control where their data goes or who can see it. That creates leakage risk, weakens access control, and forces administrators to manage a complex collector configuration manually instead of enforcing policy at the platform boundary.
Why This Matters for Security Teams
Shared telemetry looks efficient until multiple tenants can influence the same ingest path, retention policy, and output destination. In that setup, the cluster stops behaving like a neutral pipe and starts acting like a shared trust boundary. The real issue is not volume, it is control: once logs and traces are pooled, the team must prove segregation, routing integrity, and access boundaries for every destination the collector can reach.
That matters because telemetry often contains high-value operational detail, including request paths, resource names, error strings, token fragments, and environment metadata. If routing is open-ended, a misrouted stream can leak one tenant’s telemetry into another tenant’s storage or analytics tool, and that failure is hard to spot after the fact. Security teams usually discover the weakness when they try to answer a simple question about data location and find the collector can be reconfigured faster than policy can be enforced.
For containerised environments, the handling problem is amplified by the platform itself. NIST SP 800-190 Container Security is useful here because it treats the container stack, registry, orchestrator, and runtime as a connected security surface rather than isolated components. In practice, many teams discover the weakness only after a routing exception, not through deliberate tenant design.
How It Works in Practice
A common kubernetes cluster can collect telemetry safely only when routing is intentionally constrained. Without that constraint, the collector becomes a policy choke point where one misconfiguration affects every workload sharing the path. The practical risk comes from three places: where telemetry is accepted, where it is tagged, and where it is allowed to leave.
A workable pattern is to treat routing as an enforced control, not an operator convenience. Teams usually need to define tenant labels early, validate them at ingestion, and bind each label set to an approved output. If the collector supports dynamic configuration, that flexibility must be fenced by policy, because freeform routing turns a control plane feature into a data leakage path.
Key checks include:
- Telemetry from each namespace or workload is tagged before processing, not after export.
- Routing rules are centrally controlled and not edited ad hoc by application teams.
- Destination permissions are restricted so a route cannot write to arbitrary stores.
- Collector logs are retained so misroutes can be traced back to the rule change that caused them.
- Cross-tenant joins are blocked unless they are explicitly required and reviewed.
This is also where container security guidance helps. NIST SP 800-190 Container Security reinforces the need to secure the orchestration and runtime layers that make shared collection possible in the first place, because collector compromise or misconfiguration can widen the blast radius beyond a single workload. The weakest point is usually not the telemetry format itself, but the freedom to point one shared collector at many back ends without tenant-bound policy enforcement.
These controls tend to break down when teams rely on per-team exception handling for routing, because exceptions accumulate faster than any one administrator can reliably review them.
Common Variations and Edge Cases
Tighter telemetry routing often increases operational overhead, so teams have to balance isolation against flexibility. That tradeoff is most visible in hybrid clusters, shared platform services, and environments where security, SRE, and application teams all want different sinks for the same data.
One common edge case is observability tooling that enriches events before export. If enrichment happens in a shared processor, the processor itself can become a source of tenant bleed even when final storage is separated. Another is incident response: broad access to logs may be acceptable for a small on-call group, but not for all application owners, especially when traces include request identifiers that can reveal another tenant’s workload structure.
For organisations that need frequent routing changes, the safest model is usually a small set of approved patterns rather than free routing at runtime. That may feel restrictive, but it reduces the chance that a temporary debugging need becomes a permanent cross-tenant exposure. In practice, teams often overestimate how much routing freedom they need and underestimate how difficult it is to audit later.
When shared telemetry must support regulated workloads, treat routing exceptions as controlled data-handling decisions, not as ordinary platform tweaks. The closer the collector gets to arbitrary destination selection, the more it behaves like a shared secrets or records system, with all of the governance burden that implies.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Shared telemetry needs controlled access and tenant segregation. |
| PR.DS — Data Security | Telemetry routing can expose sensitive operational data across tenants. | |
| GV.PO — Policy | Tenant-aware routing depends on enforceable platform policy. | |
| Recommendation — Restrict who can route, read, and export telemetry across tenant boundaries. Classify telemetry and enforce protections before export and storage. Define routing policy centrally and prohibit ad hoc destination changes. | ||
| CIS Controls v8 | 6 — Access Control Management | Restricts who may change telemetry destinations and view shared data. |
| 3 — Data Protection | Telemetry often contains sensitive fields that need handling controls. | |
| Recommendation — Grant only approved operators permission to alter telemetry routing paths. Protect telemetry content and limit exposure across collection and export. | ||
Practitioner Guidance
What to prioritise: Define tenant boundaries at ingestion and export, not inside the downstream analytics stack. If the collector can send the same event to multiple destinations, assume the routing layer is part of your data-control boundary.
Decision rule: If a team can change telemetry destinations without a platform-owned approval path, treat that as a segregation failure and require central policy enforcement before production use.
Practitioner takeaway: Shared telemetry is only low-risk when routing is bounded by policy and auditable; once destination choice becomes ad hoc, the platform starts creating cross-tenant exposure instead of reducing operational friction.
Related resources from NHI Mgmt Group
- How should security teams use Kubernetes audit logs to detect risky change activity?
- Why do shared secrets become risky at Kubernetes scale?
- What breaks when security teams keep logs in separate tools instead of building a shared telemetry layer?
- Why does cyber threat hunting become more effective when teams have healthy data collection and enriched telemetry?
