Security teams should route logs at the aggregator layer, not by duplicating forwarders for every tenant. Namespace-based routing lets one centrally managed agent send events to tenant-specific aggregators while preserving separation. That reduces operational overhead and still allows platform teams to collect all logs for archive, investigation, or compliance. The key control is routing by tenant boundary, then validating that each destination receives only its intended data.
Why Tenant-Bound Log Routing Belongs at the Aggregator Layer
Shared logging pipelines work best when the routing decision happens after collection, at a central aggregation point, because the boundary you are enforcing is data separation, not agent duplication. That keeps one forwarder or collector pattern in place, while allowing the platform to fan out events to distinct tenant destinations based on namespace, account, cluster, or other tenancy metadata.
This design matters because the routing point is where you can consistently apply policy, validate destination rules, and prove that one tenant’s events are not crossing into another tenant’s storage or search path. It also avoids the drift that appears when every tenant gets its own bespoke forwarding setup, which is harder to operate and easier to misconfigure.
When the pipeline is designed well, central collection remains useful for archive, investigation, and compliance, but the tenant boundary is still enforced in the routing logic rather than left to downstream convention. That is the difference between shared transport and shared visibility.
A useful reference point for broader pipeline integrity is SLSA, which is aimed at provenance and integrity in build pipelines. The analogy is not identical, but the operational lesson is similar: central control points are easier to govern than duplicated edge logic.
What Security Teams Must Validate in a Shared Logging Design
The main control is not simply “can logs be forwarded,” but “can they be routed only to the correct tenant destination, with no spillover or silent fallback.” That means the team needs explicit rules for how tenant identity is derived, what metadata is trusted, and what happens when metadata is missing, malformed, or inconsistent across sources.
Validation should focus on the boundary conditions that create leakage risk: shared namespaces, reused collectors, wildcard destinations, and any rule that can collapse multiple tenants into the same sink. Teams should also confirm that the log schema does not expose more tenant data than intended, because routing separation can be undermined if the events themselves carry sensitive cross-tenant context.
Operationally, the logging tier should make destination mapping observable. If a platform team cannot show where a given event was sent, or cannot prove that rejected events were quarantined instead of forwarded broadly, the routing layer is not strong enough for a shared environment.
For implementation discipline, CIS Controls v8 is a good fit for account management, access control, and audit logging, while NIST SP 800-53 Rev 5 Security and Privacy Controls gives the control vocabulary for audit, configuration, and boundary enforcement. Both support the same practical point: the routing decision must be testable, not assumed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Tenant routing depends on enforcing destination access boundaries. |
| CIS 8 — Audit Log Management | Shared pipelines need auditable routing and separation evidence. | |
| Recommendation — Restrict log sink access so each tenant path can reach only its approved destination. Centralise audit logging for routing decisions and verify tenant-specific log delivery. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Routing by tenant boundary is an access-control problem over log destinations. |
| DE.CM — Continuous Monitoring | You need ongoing verification that tenant separation still holds in the pipeline. | |
| GV.OV — Oversight | Central governance is needed for a shared pipeline with multiple tenant boundaries. | |
| Recommendation — Apply access-control rules to bind each log stream to its permitted tenant destination. Monitor log routing outputs continuously for cross-tenant delivery or misrouting. Define ownership and oversight for shared logging routes, exceptions, and validation. | ||
Practitioner Guidance
What to prioritise: Define the tenant-routing rule set before scaling ingestion. The important decision is which metadata keys are authoritative for tenancy and which failure mode is safest when that metadata is absent, because a permissive fallback can silently break separation.
What to verify: Prove with test events that each tenant receives only its intended stream and that no destination can be reached through a wildcard, default, or shared catch-all path. Also verify that your archive or investigation sink is intentionally broader and separately controlled, rather than just another implicit copy of tenant traffic.
Common mistake: Duplicating forwarders per tenant often looks safer, but it usually creates more config sprawl, more drift, and more blind spots. A cleaner pattern is one centrally governed collector tier with strict destination validation and clear exception handling.
Practitioner takeaway: In a shared logging pipeline, the security objective is controlled fan-out, not collector multiplication, so the design should make incorrect routing easy to detect and hard to express.
Related resources from NHI Mgmt Group
- How should security teams design log collection in multi-tenant Kubernetes environments to avoid noisy-neighbor and configuration conflicts?
- How should security teams design authentication for multi-tenant SaaS apps?
- How should security teams prevent path traversal in Kubernetes storage drivers that use shared multi-tenant exports?
- How should teams design multi-tenant OAuth storage so token isolation does not become a false sense of security?