Every modern application needs secrets to work: the database password, a payment API key, a mail provider token, the TLS certificate that encrypts traffic, or the credentials to access a storage bucket. The problem is not that those secrets exist, but where they end up stored: in .env files, hard-coded in source code, committed to a Git repository by mistake, copied into CI/CD pipeline variables, or pasted onto a page in an internal wiki.
When a secret lives in twenty different places, it stops being a secret. Nobody knows for certain who has access, it is almost never rotated because changing it means updating all those places, and there is no audit trail of who used it or when. It only takes one developer accidentally pushing a config file to a public GitHub repository for that credential to be exposed to the bots that crawl the platform within seconds.
A secrets manager solves this problem by centralizing storage, encryption and access control. In this article we look at what it is exactly, how HashiCorp Vault works as the industry reference, what dynamic secrets are, and which alternatives — cloud and open source — you have depending on your architecture and compliance requirements.
The Problem: Secrets Scattered Across the Organization
The pattern is so common that almost everyone has lived it. Secrets spread across multiple locations, and each one adds its own kind of risk:
- check_circle .env and config files: convenient for development, but they end up copied between machines, sent over chat and forgotten on unencrypted test servers.
- check_circle Source code and Git repositories: a key embedded in code stays in the history forever, even if it is deleted later. Scans of leaked secrets on GitHub find millions of active credentials every year.
- check_circle CI/CD variables: practical, but hard to audit and often visible in build logs if they are not masked correctly.
- check_circle Wikis, shared password managers and spreadsheets: the "credentials document" that the whole team knows about and that nobody remembers to update when someone leaves the company.
The three structural risks are always the same. First, leaks: a secret exposed in a repository or a log can give direct access to production data. Second, the lack of rotation: passwords and keys that have gone unchanged for years because rotating them is too costly. And third, the lack of auditing: without a record of who accessed each secret and when, it is impossible to investigate an incident or prove compliance to an auditor.
What a Secrets Manager Is
A secrets manager is a centralized, encrypted store designed specifically to keep and deliver credentials in a controlled way. Instead of each application looking for its secrets in a local file, they all request them from a central service that verifies their identity, checks whether they are authorized, delivers the secret and logs the operation. Its four fundamental capabilities are:
- check_circle Encryption and access control: secrets are stored encrypted at rest, and only identities authenticated and authorized by a policy can read them, applying the principle of least privilege.
- check_circle Auditing: every read, write or renewal is recorded immutably, answering the key question "who accessed what and when?".
- check_circle Rotation: credentials can be changed automatically and periodically without manual intervention, reducing the exposure window.
- check_circle Dynamic secrets: credentials that are generated on the fly, with a short lifetime, and that are automatically revoked when they expire.
The difference from a personal password manager is substantial: a secrets manager is designed for automated consumption by machines and applications at scale, with an API, granular policies and full traceability — not for a person to copy and paste a password into a browser.
HashiCorp Vault: the De Facto Standard
HashiCorp Vault is the industry reference for secrets management. Its model is based on encrypted storage accessed only through policies, and its versatility comes from secrets engines, modules that Vault enables to cover each type of need:
- arrow_right KV (Key-Value): the classic store of static secrets with versioning, ideal for API keys, tokens and sensitive configuration values.
- arrow_right Databases: generates short-lived dynamic credentials for PostgreSQL, MySQL, MongoDB and other engines, creating a user on the fly and deleting it when the lease expires.
- arrow_right PKI: Vault acts as an internal certificate authority and issues short-lived TLS certificates on demand, a natural complement to a solid strategy for SSL/TLS certificates on servers.
Vault protects its master key through the seal/unseal mechanism. At startup Vault is "sealed" and cannot decrypt anything; you need to gather a minimum number of key fragments (via Shamir's Secret Sharing) or an auto-unseal backed by an HSM or a cloud KMS to "unseal" it and bring it online. That way, not even someone with access to the server can read the secrets while Vault is sealed.
Access is controlled through authentication methods (auth methods) tailored to each consumer: AppRole for applications and machines, OIDC for human users through an identity provider, and Kubernetes so a pod can authenticate with its service account. Each identity receives a token with the policies that define exactly which paths it can read or write. Every secret delivered carries an associated lease with a lifetime, and Vault can revoke it en masse in the event of an incident. The official Vault documentation details each of these components.
Dynamic Secrets: the Paradigm Shift
The most transformative concept in modern secrets management is the dynamic secret. In the traditional model, there is a static database password shared by all applications, which rarely changes and which, if leaked, grants indefinite access. The dynamic model flips that logic: the credential is created at the moment it is requested and expires shortly after.
Key idea:
With dynamic secrets, every application that needs to access the database asks Vault for a unique, temporary username and password. Vault creates them on the fly, the application uses them for the duration of its lease, and when it expires Vault deletes them automatically. A leaked secret stops being valid within minutes, not years.
The advantages are direct. The exposure window is drastically reduced: even if a credential is captured in a log, it expires on its own. Attribution improves, because each consumer has its own credentials and the audit trail shows exactly who obtained what. And rotation stops being a project: there is no need to orchestrate the change of a shared password across dozens of services, because there never was a shared password. It is a fundamental piece of a Zero Trust architecture, where no identity is considered trustworthy permanently.
Alternatives to HashiCorp Vault
Vault is powerful, but it is not the only option, and it is not always the most suitable. The ecosystem offers alternatives depending on whether you prefer a managed cloud service, a GitOps approach or a self-hosted open source solution:
- arrow_right Cloud secret managers: AWS Secrets Manager, Azure Key Vault and Google Cloud Secret Manager integrate secrets management and KMS with the rest of their services. Convenient and operations-free, but they tie your security to the provider and take secrets out of the territory.
- arrow_right SOPS + age: encrypts secret files so they can be versioned in Git securely. It fits perfectly into GitOps workflows, although it offers neither dynamic secrets nor real-time access auditing.
- arrow_right Sealed Secrets: designed for Kubernetes, it lets you keep encrypted secrets in the repository and have a controller decrypt them inside the cluster. Simple, but limited to static Kubernetes secrets.
- arrow_right Infisical and OpenBao: Infisical is a modern open source platform focused on developer experience; OpenBao is the open fork of Vault under the Linux Foundation, compatible with its API and its secrets engines.
The following table summarizes the key differences to guide the decision based on your deployment model, your dynamic secrets needs, cost and operational complexity:
| Solution | Model | Dynamic secrets | Cost | Complexity |
|---|---|---|---|---|
| HashiCorp Vault | Self-hosted / SaaS | Yes (native) | Medium | High |
| OpenBao | Self-hosted | Yes (native) | Low (open source) | High |
| AWS Secrets Manager | Cloud | Partial (rotation) | Medium (per secret) | Low |
| Azure Key Vault | Cloud | Partial | Medium | Low |
| SOPS + age | Self-hosted (GitOps) | No | Free | Low |
| Sealed Secrets (K8s) | Self-hosted | No | Free | Medium |
| Infisical | Self-hosted / SaaS | Partial | Low (open source) | Medium |
Best Practices, Zero Trust and Compliance
Adopting a secrets manager is the first step, but its value depends on how it is operated. These are the practices that make the difference:
- check_circle Never secrets in Git: not in the code, not in config files, not in the history. Complement the manager with secret scanning in pipelines to block accidental commits.
- check_circle Automatic rotation and dynamic secrets: prefer short-lived credentials over eternal static passwords whenever possible.
- check_circle Least privilege: each identity accesses only the secrets it needs, through granular policies per path and per action.
- check_circle Auditing enabled and reviewed: audit logs are only useful if they are kept securely and monitored to detect anomalous access.
- check_circle HSM for root keys: protect the seal key and master keys with a hardware security module, so they never exist in plaintext on disk.
All of this fits naturally into a Zero Trust model: no network, identity or service is trusted by default, and every access to a secret is authenticated, authorized and logged. On top of that, regulatory frameworks such as NIS2 and ISO 27001 explicitly require access control, encryption of sensitive data and traceability. A well-operated secrets manager is one of the most effective ways to demonstrate those controls to an auditor, as part of a comprehensive security strategy.
EasyDataHost: Vault and OpenBao on Sovereign Infrastructure
Cloud secret managers are convenient, but they mean your most sensitive keys live on a third party's infrastructure outside your control and, often, outside the territory. When data sovereignty or regulatory compliance is a requirement, self-hosting the secrets manager is the best option. At EasyDataHost we help you deploy it on Spanish infrastructure:
- arrow_right Hosting of HashiCorp Vault or OpenBao on dedicated servers in our datacenter in Spain, with full control over the root and seal keys.
- arrow_right High-availability deployments with encrypted storage, backups and auto-unseal backed by an HSM or internal KMS.
- arrow_right Integration with your applications, Kubernetes clusters and CI/CD pipelines through the right authentication methods (AppRole, OIDC, Kubernetes).
- arrow_right Operation and maintenance of the service through our managed services, so your team can focus on development, not on operating the manager.
All our infrastructure runs in our own datacenter in Spain, with ISO 27001 certification and ENS compliance. If you want to centralize your organization's secrets management without handing control to a hyperscaler, contact our team for a technical assessment with no obligation.
Frequently Asked Questions
What is a dynamic secret and why is it more secure?
It is a credential that the manager generates on the fly when an application requests it, with a short lifetime (a lease) after which it is automatically revoked. Instead of sharing a static password that can leak and never expires, each consumer receives unique, temporary credentials. If they leak, they stop being valid within minutes, and the audit log shows who requested which credential and when.
Can I self-host HashiCorp Vault in Spain instead of using a cloud service?
Yes. Both Vault and OpenBao are self-hostable. At EasyDataHost you can deploy them on dedicated servers in our datacenter in Spain, keeping full control over the root and seal keys, with ISO 27001 and ENS compliance. It is the preferred option when data sovereignty or compliance require secrets to stay within the territory.
What is the difference between Vault and OpenBao?
OpenBao is an open source fork of Vault, created after Vault switched to the BSL license. It keeps compatibility with the secrets engines, authentication methods and API of Vault, but under the MPL 2.0 license governed by the Linux Foundation. For most self-hosted use cases they are interchangeable; OpenBao appeals to those looking for a permissive license and community governance.
Conclusion
Secrets scattered across files, code and repositories are a security debt that is sooner or later paid with a breach. Centralizing them in a secrets manager turns that risk into an auditable control:
- arrow_right A secrets manager provides encrypted storage, access control, auditing, rotation and dynamic secrets in a single central service.
- arrow_right HashiCorp Vault is the de facto standard, with secrets engines (KV, databases, PKI), seal/unseal and multiple authentication methods.
- arrow_right There are alternatives for every context: cloud secret managers, SOPS+age for GitOps, sealed-secrets on Kubernetes, and Infisical or OpenBao as open options.
- arrow_right The best practices — never secrets in Git, rotation, least privilege, auditing and HSM — align secrets management with Zero Trust and with NIS2 and ISO 27001.