Vault de HashiCorp para gestión de secretos

Actualizado: 2026-05-03

La gestión de secretos es uno de esos temas donde todos saben que los .env en el servidor son mala práctica, pero que pocos equipos corrigen hasta que hay un incidente. HashiCorp Vault^[1] es la solución más madura del ecosistema y, más allá del hype, resuelve problemas concretos que persisten en la mayoría de infraestructuras.

Puntos clave

• Vault ataca tres patologías comunes: secretos estáticos distribuidos, falta de trazabilidad de acceso y separación débil entre roles.
• Los secretos dinámicos — credenciales efímeras generadas al pedir — son la característica diferencial más importante frente a un KV protegido.
• Auto-unseal con AWS/GCP KMS es imprescindible para alta disponibilidad; nunca operar con un único nodo en producción.
• La integración con Kubernetes via Vault Agent Injector elimina tokens de autenticación estáticos en pods.
• El root token debe revocarse tras el setup inicial; políticas granulares por servicio son la norma.

Qué problemas resuelve

Tres patologías típicas que Vault ataca:

• Secretos estáticos distribuidos. El mismo password en 15 servidores, copiado manualmente, imposible de rotar sin un despliegue coordinado. Vault centraliza y rota.
• Sin trazabilidad de acceso. Nadie sabe quién accedió a qué secreto ni cuándo. Vault audita cada operación.
• Separación débil entre roles. Todo el equipo conoce todos los passwords. Vault ofrece políticas granulares por rol/servicio.

Arquitectura en 60 segundos

Vault funciona como servidor que almacena secretos en un backend (Consul, integrated storage, etc.) y los sirve cifrados. Sus componentes principales son:

• Secret engines: distintos tipos de secretos — KV genérico, bases de datos dinámicas, certificados PKI, AWS IAM, SSH. Cada uno con su API específica.
• Auth methods: cómo se autentican los clientes — tokens, userpass, Kubernetes service accounts, AWS IAM, OIDC. Determina qué políticas se aplican.
• Policies: reglas HCL que definen qué paths del secret store puede leer/escribir un cliente. Granulares por verbo y ruta.
• Audit devices: log de toda operación — file, syslog, socket. Imprescindible para compliance.

Un ejemplo práctico: dynamic secrets

Supongamos un servicio que necesita credenciales de base de datos. Sin Vault están en .env:

DB_USER=api_service
DB_PASSWORD=AbCdEf1234XYZ

Con Vault y 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 genera un usuario efímero en la base de datos en el momento (TTL configurable, p. ej. 1 hora). Cuando expira, Vault lo revoca automáticamente. Si hay una brecha, las credenciales filtradas caducan en minutos, no en años.

Patrones operativos relevantes

Secretos dinámicos vs. estáticos

Vault soporta ambos. Los dinámicos (generados al pedir) son más seguros, pero no todos los sistemas los soportan bien. Los estáticos con rotación automática — Vault rota el secreto periódicamente — son un buen término medio para sistemas legacy.

Auto-unseal

Al arrancar, Vault está “sellado”: los secretos cifrados no son accesibles hasta usar una clave maestra. Auto-unseal con AWS KMS, GCP KMS o Transit engine elimina la necesidad de introducir claves manualmente. Imprescindible para alta disponibilidad.

Integración con Kubernetes

Vault Agent Injector^[2] inyecta secretos en pods como ficheros montados, sincronizados automáticamente. El pod nunca ve un token de autenticación estático — autentica con su ServiceAccount de Kubernetes.

Integración con CI/CD

GitHub Actions, GitLab CI y Jenkins pueden autenticarse a Vault con tokens de corta duración generados por OIDC o JWT. El pipeline pide los secretos al ejecutar, sin almacenarlos en variables de entorno persistentes.

Qué conviene no hacer

Estos son los errores que se repiten:

• Usar Vault solo como “KV bonito”. Si solo almacenas pares clave-valor estáticos, la ganancia sobre un .env bien protegido es marginal. El valor viene de dynamic secrets, rotación y auditoría.
• Dejar el root token activo. Tiene permisos completos y no debe usarse más allá del setup inicial. Revocarlo después de generar tokens y políticas operativas.
• Una sola instancia sin HA. Vault caído = despliegues caídos. En producción, al menos 3 nodos con raft o Consul.
• Políticas permisivas tipo wildcard. path "*" { capabilities = ["read"] } anula el valor de Vault. La granularidad por servicio es la norma.

Alternativas

Aunque Vault es el referente, hay otras opciones válidas:

• AWS Secrets Manager / GCP Secret Manager / Azure Key Vault: si estás 100 % en un solo cloud, la integración nativa puede ser suficiente.
• Infisical^[3]: open-source más reciente, UI más amigable, menor madurez en dynamic secrets.
• 1Password for Teams^[4]: adecuado para equipos pequeños donde los secretos son mayormente humanos.
• Sealed Secrets + External Secrets Operator: patrón GitOps para K8s sin necesidad de Vault.

Ver también cómo la directiva NIS2 refuerza la necesidad de gestión formal de secretos en ciertos sectores, y ataques a la cadena de suministro — donde las credenciales comprometidas son un vector de entrada frecuente.

Conclusión

Vault es la opción más completa para gestión de secretos, pero también la más exigente operativamente. Para equipos que todavía viven con .env distribuidos, el primer paso es decidir si la inversión operativa de Vault se justifica o si una alternativa más simple cubre el caso. Lo que no es opción es “seguir como estamos”.

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