Mounting host log paths turns the node filesystem into a security boundary that logging agents can cross. Once an agent can read the shared host folder, Kubernetes RBAC no longer limits which application logs it can process. In multi-tenant clusters, that can expose logs across teams or customers and undermine least-privilege access control.
Why host log mounts change the trust boundary
In a multi-tenant cluster, the risk is not just that a DaemonSet can read logs. It is that the logging pod is now trusted with a host-level path that sits outside Kubernetes namespace boundaries. Once a container can traverse the node filesystem, the separation between tenants becomes dependent on node path design, mount scope, and the agent’s own access hygiene rather than on Kubernetes policy alone.
That matters because host-mounted log paths often aggregate data from many workloads on the same node. A privileged or overly broad log agent can therefore become a cross-tenant observation point, especially if it is allowed to read directories recursively or if application teams write sensitive data to stdout, files, or sidecar buffers that end up on the host.
A useful way to think about it is that the mount creates a new boundary: the node, not the namespace, becomes the object being protected. If that node boundary is shared by multiple customers or business units, any logging mistake can turn into unintended disclosure at cluster scale. The underlying issue is described well in NIST SP 800-190 Container Security and in NHI Mgmt Group’s Ultimate Guide to Non-Human Identities, where overbroad machine access and weak governance are recurring failure modes.
Where cross-tenant exposure usually comes from
The most common failure is overcollection. A DaemonSet is deployed on every node, so it inherits a wide physical footprint by design. If it mounts a shared log directory, it may ingest logs for pods that belong to different teams, different namespaces, or different customers when the node hosts mixed tenancy.
Another failure mode is overpermission inside the agent itself. Even if the mount is intended to be read-only, the container still needs file system visibility, parsing logic, buffering, and often network egress to forward events. That combination can expose raw log content to operators, downstream pipelines, or a compromised agent process. In environments with poor log hygiene, the problem is amplified by secrets, tokens, session data, and error traces appearing in application logs.
For container-specific controls, NIST SP 800-190 Container Security is the clearest external reference because it treats image, runtime, orchestration, and host integration as separate risk surfaces. A parallel practical concern is overprivileged non-human access, which is why NHIMG’s Docker Hub Auth Secrets in Container Images and Massive Docker Hub Secrets Leak are relevant analogies: once shared infrastructure can read broadly, exposure spreads faster than teams expect.
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, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access permissions and authorizations | Host log mounts can bypass tenant isolation without tight access scoping. |
| PR.DS-5 — Data is protected | Shared host logs can expose sensitive tenant data if not segmented and handled carefully. | |
| Recommendation — Restrict log-agent access to the minimum host paths needed for collection. Protect log data at rest and in transit, and avoid broad raw-log exposure. | ||
| CIS Controls v8 | 6.3 — Use of Administrative Privileges | DaemonSet log access becomes risky when the agent has broader host-level privileges than required. |
| 3.4 — Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers | Host mounts are a configuration choice that can widen the node trust boundary in shared clusters. | |
| Recommendation — Remove unnecessary privileges from log collectors and constrain their host access. Harden node and workload configuration so host mounts are narrowly scoped and reviewed. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Not selected |
Practitioner Guidance
What to verify: Confirm exactly which host paths are mounted, whether the agent can recurse beyond the intended directory, and whether multiple tenants can ever write to the same node-local log location. If the answer is unclear, treat the mount as a data-sharing boundary, not a harmless implementation detail.
Decision rule: If the logging path can contain application data from more than one trust domain, reduce the mount scope or split the logging plane before you trust the DaemonSet. If the only safe way to make the agent work is broad host visibility, the design is already too permissive for a shared cluster.
What good looks like: The agent reads only the minimum required host directory, stores no unnecessary raw log payloads, and is constrained so that one tenant’s telemetry cannot be silently consumed as another tenant’s operational data. In practice, that means least-privilege file access, tight path scoping, and deliberate log segregation at the node level.
Practitioner takeaway: The main question is not whether the DaemonSet can collect logs, but whether its host mount turns a node-local convenience into a cross-tenant read path that defeats namespace isolation.
Related resources from NHI Mgmt Group
- Why does mounting node log paths create risk in multi-tenant Kubernetes environments?
- Why do over permissive Kubernetes network policies increase breach risk in multi tenant clusters?
- Why do shared-schema multi-tenant systems create cross-customer risk?
- Why do vector databases create governance risk in multi-tenant AI systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
