HashiCorp Vault for Secrets Management

Actualizado: 2026-05-03

Secrets management is one of those topics where everyone knows .env files on servers are bad practice, but few teams fix it until there’s an incident. HashiCorp Vault^[1] is the ecosystem’s most mature solution and, beyond the hype, solves concrete problems that persist in most infrastructures.

Key takeaways

• Vault addresses three common pathologies: distributed static secrets, lack of access traceability, and weak role separation.
• Dynamic secrets — ephemeral credentials generated on demand — are the most important differentiating feature over a protected KV store.
• Auto-unseal with AWS/GCP KMS is essential for high availability; never run a single node in production.
• Kubernetes integration via Vault Agent Injector eliminates static auth tokens in pods.
• The root token must be revoked after initial setup; per-service granular policies are the norm.

Problems it solves

Three typical pathologies Vault addresses:

• Distributed static secrets. The same password on 15 servers, copied manually, impossible to rotate without coordinated deployment. Vault centralises and rotates.
• No access traceability. Nobody knows who accessed which secret, or when. Vault audits every operation.
• Weak role separation. The whole team knows every password. Vault offers granular policies by role/service.

Architecture in 60 seconds

Vault works as a server that stores secrets in a backend (Consul, integrated storage, etc.) and serves them encrypted. Its main components:

• Secret engines: different secret types — generic KV, dynamic database credentials, PKI certificates, AWS IAM, SSH. Each with its specific API.
• Auth methods: how clients authenticate — tokens, userpass, Kubernetes service accounts, AWS IAM, OIDC. Determines which policies apply.
• Policies: HCL rules defining which secret-store paths a client can read/write. Granular by verb and path.
• Audit devices: log of every operation — file, syslog, socket. Essential for compliance.

A practical example: dynamic secrets

Say a service needs database credentials. Without Vault they’re in .env:

DB_USER=api_service
DB_PASSWORD=AbCdEf1234XYZ

With Vault and dynamic secrets:

import hvac
client = hvac.Client(url='https://vault.example.com', token=os.environ['VAULT_TOKEN'])
creds = client.secrets.database.generate_credentials(name='api_service')
db = psycopg2.connect(user=creds['data']['username'], password=creds['data']['password'], ...)

Vault generates an ephemeral database user on demand (configurable TTL, e.g. 1 hour). When it expires, Vault revokes it automatically. If there’s a breach, leaked credentials expire in minutes, not years.

Relevant operational patterns

Dynamic vs. static secrets

Vault supports both. Dynamic (generated on request) are safer, but not all systems support them well. Static with automatic rotation — Vault rotates periodically — is a good middle ground for legacy systems.

Auto-unseal

At startup, Vault is “sealed”: encrypted secrets aren’t accessible until a master key is used. Auto-unseal with AWS KMS, GCP KMS, or Transit engine removes the need to enter keys manually. Essential for high availability.

Kubernetes integration

Vault Agent Injector^[2] injects secrets into pods as mounted files, automatically synced. The pod never sees a static auth token — it authenticates with its Kubernetes ServiceAccount.

CI/CD integration

GitHub Actions, GitLab CI, and Jenkins can authenticate to Vault with short-lived tokens generated via OIDC or JWT. The pipeline requests secrets at runtime, without storing them in persistent environment variables.

What not to do

These are the recurring mistakes:

• Use Vault only as “fancy KV”. If you only store static key-value pairs, the gain over a well-protected .env is marginal. Value comes from dynamic secrets, rotation, and auditing.
• Leave the root token active. It has full permissions and shouldn’t be used beyond initial setup. Revoke it after generating operational tokens and policies.
• Single instance, no HA. Vault down = deployments down. In production, at least 3 nodes with raft or Consul.
• Permissive wildcard policies. path "*" { capabilities = ["read"] } nullifies Vault’s value. Per-service granularity is the rule.

Alternatives

Though Vault is the reference, other valid options:

• AWS Secrets Manager / GCP Secret Manager / Azure Key Vault: if you’re 100% in a single cloud, native integration may be enough.
• Infisical^[3]: newer open-source, friendlier UI, less mature in dynamic secrets.
• 1Password for Teams^[4]: suitable for small teams where secrets are mostly human.
• Sealed Secrets + External Secrets Operator: GitOps pattern for K8s without needing Vault.

Also see how the NIS2 directive reinforces the need for formal secret management in certain sectors, and supply-chain attacks — where compromised credentials are a frequent entry vector.

Conclusion

Vault is the most complete secrets-management option, but also the most operationally demanding. For teams still living with distributed .env files, the first step is deciding whether Vault’s operational investment is justified or a simpler alternative covers the case. What’s not an option is carrying on as before.

1. HashiCorp Vault
2. Vault Agent Injector
3. Infisical
4. 1Password for Teams