Mounting the host log path turns the node filesystem into a security boundary, and once a log agent crosses that boundary, Kubernetes RBAC no longer limits which application logs it can process. In shared clusters, that means one collector can potentially read logs across tenants. The risk is not just exposure, but the loss of practical isolation after collection.
Why This Matters for Security Teams
Mounting node log paths changes who can see operational data, because the collector is no longer limited to the application boundary. In a multi-tenant cluster, that can turn a routine observability pattern into a cross-tenant exposure path if the node filesystem contains logs from pods that belong to different workloads or teams. The security issue is not the log format itself, it is the trust boundary created when host access is granted.
This is why container guidance treats host mounts as a material risk surface. NIST SP 800-190 Container Security emphasizes that container runtime and host interactions can bypass the isolation teams assume they have inside the orchestrator. Once a log agent can read node paths directly, the practical control plane shifts from Kubernetes authorization to filesystem permissions and node-level hardening. In practice, teams often discover this only after a centralized collector has been granted broad read access across the cluster, rather than through a deliberate isolation review.
How It Works in Practice
Most logging stacks need a way to discover pod output, enrich it, and ship it to a central destination. When that is done through a hostPath mount or equivalent access to the node log directory, the collector gains visibility into whatever is written there on that node, not just the logs for the workload that owns the collector. That creates two practical effects: it can expand the blast radius of a compromised logging component, and it can make access reviews misleading because the important privilege is now on the node, not in the Kubernetes object spec.
- A collector that reads node logs may see multiple namespaces, teams, or tenants if they share the same node.
- RBAC may still look tight while the effective read scope is much broader at the filesystem layer.
- Any compromise of the logging path can become a discovery path for sensitive operational data, credentials in logs, or incident context.
- Node-level access also makes segregation depend on scheduling, log routing, and path layout, which are easier to misconfigure than people expect.
That is why the implementation question is really about boundary design: whether the collector should read only its own workload output, or whether it is being given a shared view of the node. NIST Cybersecurity Framework 2.0 is useful here because the control problem spans govern, protect, detect, and recover, not just one logging setting. These controls tend to break down when log paths are shared across tenants and the platform assumes namespace separation is enough.
Common Variations and Edge Cases
Tighter log access often increases operational overhead, because teams must trade easier collection for stronger isolation and more explicit routing. That trade-off becomes sharper in clusters where multiple tenants share nodes, where a single DaemonSet-style collector is used, or where compliance teams expect logs to be centrally available without understanding the underlying path permissions.
One common variation is to mount only the minimum directory needed for a workload rather than the full node log tree. Another is to use sidecar or application-level shipping so the collector stays inside the workload boundary. Those approaches reduce exposure, but they can complicate standardisation, retention, and debugging. OWASP API Security Top 10 is a useful reminder that broad read access often creates broken authorisation patterns even when the control was added for convenience. The trade-off gets hardest when teams rely on shared nodes for cost efficiency, because the operational simplicity of one collector can hide a much wider data reach than the owner intended.
Risk and Threat Considerations
The main risk is loss of tenant isolation at the log collection layer. Even if workloads are isolated at the Kubernetes object level, node log mounts can expose data across namespaces or tenants when the collector has filesystem access broader than its intended scope.
Failure mechanism: The risk materialises when a shared collector, DaemonSet, or log forwarder is granted read access to host paths that aggregate logs from more than one workload. At that point, the effective access control shifts from Kubernetes policy to node filesystem visibility, and any compromise or misconfiguration in the collector can be abused for cross-tenant reconnaissance or data exposure.
Impact: Sensitive operational details, error traces, request metadata, or embedded secrets in logs can become visible outside the owning tenant. In a shared cluster, that undermines separation guarantees, enlarges the blast radius of a logging failure, and can complicate incident response because the collector itself becomes a high-value access path.
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 | Host log mounts change practical access boundaries for shared cluster logs. |
| PR.PT — Protective Technology | Node log path mounts are a protective-technology boundary decision in containerised environments. | |
| DE.CM — Continuous Monitoring | Central logging is part of detection, but broad mounts can distort what is observed. | |
| Recommendation — Limit collector access to the smallest log scope that preserves tenant isolation. Harden log collection paths and remove unnecessary host filesystem exposure. Validate that monitoring coverage reflects tenant boundaries, not just node visibility. | ||
| CIS Controls v8 | 6 — Access Control Management | Shared log mounts can create overbroad access to tenant data and operational records. |
| 12 — Network Infrastructure Management | Cluster logging paths and node access must be managed as part of infrastructure hardening. | |
| Recommendation — Restrict log-reader permissions and review every path that crosses the node boundary. Separate logging duties from general node access and harden the collector runtime. | ||
Practitioner Guidance
What to prioritise: Treat every host log mount as a privileged design choice, not a default logging convenience. If the collector can read more than one tenant’s logs, document that exposure explicitly and verify whether the business actually accepts it.
What to verify: Check the exact node paths mounted into the collector, the namespaces or tenants represented on those nodes, and whether the collector can traverse beyond the intended workload boundary. Also verify where log enrichment happens, because enrichment jobs often inherit broader read scope than the logging team expects.
- Confirm whether logs contain secrets, tokens, session identifiers, or customer data before broadening access.
- Prefer workload-scoped shipping where shared-node access is unnecessary.
- Review the collector like any other privileged component, including patching, image trust, and runtime hardening.
- Escalate any cross-tenant read path as a design exception, not a minor configuration choice.
Practitioner takeaway: The decisive question is not whether logs are being collected centrally, but whether the collection path preserves the isolation boundaries the cluster is supposed to enforce.
Related resources from NHI Mgmt Group
- Why do semantic caches create risk in multi-tenant AI environments?
- Why do tenant-scoped credentials create cross-cluster risk in managed Kubernetes environments?
- Why do shared-schema multi-tenant systems create cross-customer risk?
- Why do multi-cloud environments create more identity risk than single-cloud estates?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
