Vault-based access retrieves secrets only when needed and allows policy-based control over who or what can request them. Secret mounting places credential material directly into the runtime environment, which is simpler to deploy but harder to segment, revoke, and trace across Kubernetes workloads.
Why This Matters for Security Teams
The difference between vault-based secret access and secret mounting is not just deployment style. It changes how credentials are governed, audited, rotated, and revoked across workloads. Vault-based access supports tighter policy enforcement because the secret is requested at runtime, usually by a workload with an identity that can be authenticated and authorized. Secret mounting, by contrast, increases exposure because credential material is present in the environment and can persist longer than intended.
That distinction matters in Kubernetes, CI/CD, and automation pipelines where non-human identities often outnumber human users. The OWASP Non-Human Identity Top 10 treats secret handling as a governance issue, not just a storage choice, because weak lifecycle control creates a direct path to privilege misuse. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls also reinforces access control, auditability, and credential management as core defensive requirements.
In practice, many security teams encounter secret sprawl only after a mounted credential has already been copied, cached, or reused outside the intended workload boundary.
How It Works in Practice
Vault-based access typically works by separating the secret from the application image and runtime config. A workload authenticates to a vault using its identity, receives only the specific secret it is allowed to use, and often gets a short-lived token or lease in return. That makes it easier to rotate credentials, shorten exposure windows, and trace which workload requested which secret.
Secret mounting usually injects a secret into a pod, container, or host runtime as a file, environment variable, or mounted volume. This is operationally convenient because the application can read the secret directly, but the tradeoff is that the secret may be easier to discover, snapshot, or reuse if the runtime is compromised.
- Vault-based access is stronger when workloads can authenticate with a stable identity and request secrets just in time.
- Secret mounting is easier for legacy applications that expect local files or environment variables at startup.
- Vault-based access improves revocation because access can be cut off centrally without waiting for redeployment.
- Secret mounting can be acceptable for low-risk internal services, but only when rotation and runtime isolation are mature.
Practitioners should also distinguish between secret retrieval and secret persistence. A vault can still be misused if applications cache credentials indefinitely, and mounting can be acceptable for short-lived jobs if the mounted secret is ephemeral and tightly scoped. The control objective is not the storage mechanism alone, but whether the secret is exposed to fewer identities, for less time, with better audit evidence. These controls tend to break down in multi-tenant Kubernetes clusters with shared namespaces and weak workload identity because the mount path becomes easier to inspect and reuse.
Common Variations and Edge Cases
Tighter secret handling often increases operational overhead, requiring organisations to balance deployment simplicity against revocation speed, traceability, and blast-radius reduction. There is no universal standard for when mounting becomes unacceptable, but current guidance suggests the decision should depend on workload sensitivity, privilege level, and the maturity of identity controls around the runtime.
Some environments need hybrid patterns. For example, a job may mount a bootstrap token only long enough to authenticate to a vault, then discard the token and fetch the real secret on demand. Other systems use sidecars or agents to refresh secrets transparently, which can reduce application changes but introduces its own operational dependencies.
Edge cases often appear in container image build pipelines, batch processing, and service meshes. A mounted secret may be practical when an application cannot call a vault directly, but it should still be paired with short expiry, strict namespace isolation, and logging that can support incident response. Where regulated data or payment credentials are involved, teams should treat mounting as a higher-risk exception rather than a default pattern. The main distinction is that vault-based access is identity-driven and revocable at request time, while secret mounting is convenience-driven and easier to misuse if runtime boundaries are weak.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-6 | Secret handling is a core NHI lifecycle risk when workloads authenticate with credentials. |
| NIST CSF 2.0 | PR.AC-1 | Identity-based access to secrets maps to access control and authorization expectations. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is essential when deciding how much secret exposure a workload gets. |
Treat mounted secrets as NHI assets and enforce short-lived, traceable, revocable access paths.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
