Vault de HashiCorp para gestión de secretos

javi
Candado y llaves representando gestión segura de secretos

La gestión de secretos es uno de esos temas donde todos sabemos que los .env en el servidor son mala práctica, pero que pocos equipos arreglan hasta que hay un incidente. HashiCorp Vault 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.

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 un servidor que almacena secretos en un backend (consul, integrated storage, etc.) y los sirve cifrados. Componentes:

  • Secret engines: distintos tipos de secretos (KV genérico, bases de datos dinámicas, certificados PKI, AWS IAM, SSH). Cada uno con 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. Granular por verbo y ruta.
  • Audit devices: log de toda operación (file, syslog, socket). Imprescindible para compliance.

Un ejemplo práctico

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

DB_USER=api_service
DB_PASSWORD=AbCdEf1234XYZ

Con Vault + 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 (con 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. Dinámicos (generados al pedir) son más seguros pero no todos los sistemas los soportan bien. Estáticos con rotación automática (Vault rota el secreto periódicamente) son un buen término medio para legacy.

Auto-unseal

Al arrancar, Vault está “sellado” — los secretos cifrados no son accesibles hasta que se use 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 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.

Integración con CI/CD

GitHub Actions, GitLab CI, Jenkins — todos 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

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, auditoría.
  • Dejar el root token activo. Este token tiene permisos completos y no debería 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. Granularidad por servicio es la regla.

Alternativas

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

  • AWS Secrets Manager / GCP Secret Manager / Azure Key Vault: si estás 100% en un cloud, la integración nativa puede ser suficiente.
  • Infisical: open-source más reciente, UI más amigable, menor madurez en dynamic secrets.
  • 1Password for Teams: 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.

Conclusión

Vault es la opción más completa para gestión de secretos en 2023, 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”.

Síguenos en jacar.es para más sobre DevOps, seguridad y gestión de infraestructura.

Entradas relacionadas