Who is accountable when a Kubernetes CSI driver allows cross-tenant storage access through path traversal?

Accountability is shared across the driver maintainer, the platform team, and the cluster operator. Driver maintainers must validate attacker-controlled path input. Platform teams should apply admission controls and restrict PersistentVolume creation. Operators must review multi-tenant storage design and assume that any opaque identifier passed through the API can become a security boundary if no layer enforces it.

Why This Matters for Security Teams

A Kubernetes CSI driver sits directly on the trust boundary between application workloads and persistent storage. When that driver allows cross-tenant access through path traversal, the issue is not just a bug in path parsing. It becomes a multi-layer accountability problem across software supply, platform policy, and operational governance. NIST control families such as NIST SP 800-53 Rev 5 Security and Privacy Controls treat this kind of boundary failure as a control design and implementation issue, not merely a code defect.

Security teams often assume storage plugins are infrastructure details that can be delegated without deep review. That assumption breaks down quickly in multi-tenant clusters, where a single malformed path, volume handle, or mount reference can expose another tenant’s data plane. The question of accountability matters because it drives who must fix the code, who must restrict the API, and who must verify the cluster-wide blast radius. If the driver is treated as “just another internal component,” the security boundary may remain undocumented, unenforced, and untested.

In practice, many security teams encounter this only after a tenant isolation failure has already occurred, rather than through intentional threat modeling.

How It Works in Practice

The practical answer starts with shared responsibility, but the work is different at each layer. Driver maintainers are accountable for input handling, canonicalisation, and rejecting traversal sequences before any filesystem or object store action occurs. Platform teams are responsible for limiting which storage classes, volumes, and CSI capabilities are available to workloads. Cluster operators must decide whether the storage architecture is even suitable for cross-tenant use, especially when the driver exposes opaque identifiers that can be abused as path-like references.

That means the security review should include both code-level and platform-level checks. A driver may pass unit tests while still failing in production if it trusts metadata passed through Kubernetes APIs. A cluster may also appear compliant while still permitting tenant-to-tenant access through a privileged storage path. Current guidance suggests treating every externally influenced storage reference as untrusted until validated, normalized, and bound to an expected namespace or tenant scope.

• Validate all path-like input before mount, create, or publish operations.
• Restrict PersistentVolume and StorageClass creation to approved workflows.
• Audit CSI privileges, node access, and any hostPath-like behavior.
• Test for traversal, namespace confusion, and cross-tenant read and write access.
• Map the driver’s trust boundaries to storage and identity controls, not only to application ownership.

This is also where identity governance becomes relevant. A CSI driver that relies on service account context, workload identity, or opaque tokens to determine storage scope can create a non-human identity trust decision. That intersection is important because the storage action may be authorized through an identity path even when the actual path input is hostile. The OWASP Non-Human Identity Top 10 is useful here as a reminder that machine identities, tokens, and workload trust can become enforcement points when storage automation is involved.

These controls tend to break down when clusters mix shared storage, permissive CSI RBAC, and application teams that can self-provision volumes because the resulting trust chain has too many weakly governed links.

Common Variations and Edge Cases

Tighter storage controls often increase operational friction, requiring organisations to balance tenant isolation against deployment speed and self-service flexibility. That tradeoff becomes sharper in stateful platforms, managed Kubernetes environments, and hybrid clusters where the storage layer is abstracted away from application teams. Best practice is evolving, but there is no universal standard for exactly how CSI drivers should enforce tenant boundaries in every deployment model.

Some environments should treat the platform team as primary accountability because they chose the storage architecture and exposed the CSI driver cluster-wide. Others place more responsibility on the vendor or maintainer if the traversal flaw is inside the plugin itself. In regulated settings, the operator still cannot outsource accountability, because failure to test, constrain, or monitor the driver can turn a software defect into an enterprise control failure. The right question is not only who introduced the flaw, but who failed to prevent it from becoming exploitable.

Edge cases include read-only mounts that still leak metadata, backup or snapshot paths that bypass application isolation, and multi-cluster storage designs where one control plane governs several tenant zones. In those cases, identity and storage governance must be reviewed together rather than separately. Where workload identity is used to gate storage access, teams should also examine whether token scope, service account binding, or namespace trust is strong enough to resist abuse. The accountability model should be documented in platform policy, incident response playbooks, and supplier review criteria.

For control mapping, organisations often align this issue with the access, least privilege, and system integrity expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, even when the technical failure sits inside a storage plugin rather than a traditional IAM layer.

Related resources from NHI Mgmt Group

• How should security teams prevent path traversal in Kubernetes storage drivers that use shared multi-tenant exports?
• Who is accountable when vendor access reaches OT systems through convergence?
• Who is accountable when access is granted through policy-driven automation?
• Who is accountable when a small business breach spreads through weak access controls?