La gestión segura de secretos es uno de los grandes retos en entornos DevOps, cloud y Kubernetes. HashiCorp Vault se ha convertido en una de las herramientas más utilizadas para proteger credenciales, API Keys, certificados y configuraciones sensibles de forma centralizada y segura.
Soy Òscar Mas y si estás leyendo esto, es probable que tengas archivos .env repartidos por todas partes o, peor aún, algún "password" escrito en un archivo de texto plano (tranquilo, esto le pasa a todo el mundo).
Hoy vamos a hablar de HashiCorp Vault, la herramienta definitiva para poner orden a todo este caos.
¿Qué podemos guardar en Vault?
Antes de empezar, debemos preguntarnos: ¿qué guardamos exactamente en Vault?, y no hay una respuesta a esta cuestión, hay varias respuestas:
Contraseñas y Credenciales
Desde el login del administrador de la base de datos hasta las claves de acceso del usuario de test.
Tokens de API
Todas aquellas "API Keys" de servicios como Stripe, AWS o SendGrid que nunca deberían estar en el código fuente.
Certificados SSL/TLS
Vault puede gestionar (e incluso generar) tus certificados para asegurar que las comunicaciones entre tus servicios sean seguras.
Configuraciones sensibles
Hay parámetros de configuración que, aunque no sean una contraseña, no quieres que sean públicos (como URLs internas o puertos específicos).
Aparte de estas características (que no son pocas), una de las cosas más importantes es el "Secret Sprawl" (la dispersión de secretos). Este es el problema que Vault soluciona; es tener la seguridad centralizada en un solo punto, en lugar de tenerla en mil herramientas o lugares distintos.
Si todavía te preguntas si vale la pena el esfuerzo de implementarlo, aquí tienes tres motivos de peso que te harán dormir más tranquilo por las noches:
Adiós a los secretos dispersos: La misión principal es evitar que las credenciales vivan en archivos de texto, dentro del propio código o en variables de entorno inseguras.
Auditoría total (quién, qué y cuándo): En seguridad, la trazabilidad lo es todo. Vault te permite saber exactamente quién ha solicitado un secreto, en qué momento lo ha hecho y desde qué IP. Si pasa algo extraño, tienes la información para poder investigarlo.
Cifrado simplificado (Transit): Imagina que tu aplicación tiene que guardar datos bancarios. En lugar de programar toda la lógica criptográfica (que es complicada y peligrosa), envías el dato a Vault, él lo cifra y te lo devuelve. La aplicación nunca gestiona las claves maestras, solo solicita el servicio.
¿Qué es el Unseal en Vault?
A partir de estos puntos, es muy importante tener claro qué es el Unseal en Vault.
El Unseal es el proceso de introducir las claves necesarias para “desbloquear” el sistema de Vault y que pueda empezar a servir secretos. Por defecto, Vault utiliza un sistema llamado Shamir's Secret Sharing: esto es, que la clave necesaria para desbloquear Vault se divide en varias partes y necesitas un mínimo de claves para poder abrirlo. Esto evita que una sola persona tenga el control total.
Debes ser consciente de que cada vez que se reinicia el servicio de Vault, es necesario introducir estas claves, si no Vault no podrá servir los secretos que tiene almacenados. Como puede ocurrir que el sistema se reinicie en un momento en el que no podamos introducir manualmente las claves, existen diferentes formas de automatizar el Unseal y no tener que hacerlo manualmente:
- Scripts Custom (totalmente desaconsejado): Podrías hacer un script que envíe las claves automáticamente al arrancar. Es funcional y mucha gente lo hace al principio, pero es un riesgo enorme: si alguien entra en el servidor del script, tiene las claves de todo tu reino. Es como dejar la llave de la caja fuerte debajo de la alfombra de la entrada.
- Servidor de Transit: Consiste en utilizar otra instancia de Vault independiente para guardar las claves de la primera. Es una solución elegante si ya tienes un ecosistema de Vault en la empresa, delegando la confianza de un Vault al otro.
- Servicios Cloud (KMS): Esta es la opción más profesional y segura en entornos cloud. Utilizamos servicios como AWS KMS, Azure Key Vault o Google Cloud KMS. Vault delega el descifrado de su clave maestra a estos servicios gestionados. Es extremadamente seguro porque todo queda protegido por las políticas de acceso (IAM) de tu proveedor cloud.
Métodos de autenticación de Vault
Vault no tiene una lista de usuarios “estática” por defecto (aparte del root), para poder acceder a su sistema. Utiliza diferentes métodos de autenticación para validar tu identidad y darte un Token, como por ejemplo:
Tokens (El método nativo)
Es el corazón de Vault. Al final, uses el método que uses, Vault te dará un Token.
Userpass
El método más clásico. Creamos un usuario y una contraseña directamente dentro de Vault.
LDAP / Active Directory
Si trabajas en una empresa grande, seguramente ya tenéis un Active Directory. Vault puede conectarse a vuestro sistema, para utilizar sus credenciales corporativas para entrar.
Kubernetes
Si utilizas K8s, Vault puede validar la identidad de un Pod mediante su Service Account.
AppRole
Este es el método preferido para máquinas o aplicaciones. En lugar de un usuario/contraseña, la aplicación utiliza un RoleID y un SecretID (como si fuera un usuario y contraseña para robots).
GitHub
Muy popular entre desarrolladores.
Diferencias entre KV1 y KV2
Otro punto importante es saber que cuando guardamos datos en Vault, hay dos formas de guardarlos, utilizando KV1 y KV2 (KV significa: Key-Value) y la diferencia es:
- KV1: Solo guarda el valor actual. Si escribes sobre una clave existente, el valor antiguo desaparece para siempre.
- KV2: Cada vez que cambias un secreto, Vault no borra el anterior, sino que crea una versión nueva (v1, v2, v3...). Puedes recuperar un valor antiguo en cualquier momento.
Static and Dynamic Secrets
Para terminar, hay que entender que Vault no solo guarda datos (secretos, configuraciones, etc...), existe un mundo maravilloso llamado "dynamic secrets":
- Static secrets: Son los de toda la vida. Tú guardas una contraseña, la montas en Vault y allí se queda hasta que tú la cambies manualmente.
- Dynamics Secrets: Aquí es donde ocurre la magia. Vault puede generar unas credenciales únicas para un usuario (por ejemplo, para una base de datos SQL) que solo existen mientras se utilizan o durante un tiempo predefinido y se autodestruyen después. Si alguien las roba, no le servirán de nada al cabo de poco tiempo.
Espero que este artículo os haya servido de ayuda y, como mínimo, os haya sido útil para terminar de aclarar conceptos.