Secrets Store CSI Driver

Expanded Definition

Secrets Store CSI Driver is best understood as a delivery mechanism for credentials, not as a secrets management system. In Kubernetes, it mounts secret values into a pod at runtime through a CSI volume, which means the application reads them from the filesystem instead of consuming a native Kubernetes Secret object. That distinction matters because the security properties change: the cluster no longer stores the secret in the same default object path, but the workload still depends on strong identity, provider-side protection, and tight pod-level access controls.

Definitions vary across vendors on whether this pattern counts as "secretless" or simply "less persistent" storage. NHI Management Group treats it as a runtime distribution control that can reduce some forms of exposure while increasing operational dependence on the external secrets provider and the node environment. For governance, this aligns closely with expectations in the OWASP Non-Human Identity Top 10 and with control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is treating CSI mounting as a substitute for secrets governance, which occurs when teams remove Kubernetes Secrets but leave overprivileged pod identities and weak provider access unchanged.

Examples and Use Cases

Implementing Secrets Store CSI Driver rigorously often introduces lifecycle and observability tradeoffs, requiring organisations to weigh lower stored-secret exposure against harder debugging, tighter node trust assumptions, and more complex dependency handling.

• A payment workload mounts database credentials from an external vault at startup so the secret never appears as a standard Kubernetes Secret object.
• A platform team uses dynamic secret rotation for short-lived credentials, then pairs the driver with workload identity checks to limit pod access.
• A GitOps pipeline deploys CSI volume definitions while keeping the secret value outside the repository, reducing the chance of accidental commit exposure. For deeper incident patterns, see the Guide to the Secret Sprawl Challenge.
• A multi-tenant cluster separates secret delivery per namespace so one application cannot mount another team's credentials.
• An engineering team discovers that a sidecar and the main container both can read the mounted path, showing why pod-level file permissions still matter.

These use cases are most effective when the external provider, node security, and workload identity are controlled as one chain. That is why NHI practitioners often compare the pattern with breach lessons captured in the CI/CD pipeline exploitation case study and with supply chain exposure reflected in the Reviewdog GitHub Action supply chain attack.

Why It Matters in NHI Security

Secrets Store CSI Driver matters because it changes where compromise happens, not whether compromise is possible. If the workload identity is weak, an attacker who reaches a pod, node, or attached service account can still retrieve the mounted secret at runtime. That makes the term central to NHI security, where the real control objective is to ensure that each machine identity can access only the minimum credential set, for the shortest time required. The governance question is not simply "where is the secret stored?" but "who can cause it to be delivered, read, rotated, or reused?"

NHIMG research shows how often secrets problems persist even after teams believe they have modernised their stack: 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure. That context explains why runtime mounting alone is not enough. The risk shifts from cluster object sprawl to provider misuse, pod escape, and entitlement drift. In practice, this becomes especially important during incident response, because mounted credentials may need immediate revocation, rotation, and workload re-issuance across many pods. Organisations typically encounter the operational necessity of Secrets Store CSI Driver only after a credential leak, at which point runtime secret delivery becomes unavoidable to address.

Related resources from NHI Mgmt Group

• Should organisations replace a secrets store with a unified access platform?
• Why do workflow automation platforms create NHI risk when they store secrets?
• How should retailers govern secrets at the POS edge without breaking store uptime?
• How should teams decide whether a value belongs in Secrets Manager or Parameter Store?