Instalación de Hashicorp Vault

Esta es una guía práctica y rápida de instalación de Hashicorp Vault en una máquina virtual. El propósito es poder experimentar con él, probar sus funcionalidades básicas y así animarse a dar los próximos pasos.

1. Requisitos

Una máquina virtual con Ubuntu Linux
Recursos: 1 GB de memoria, 1 vCPU, 20 GB de disco
Comprensión básica sobre Vault (artículo recomendado)

2. Instalación y arranque

Este procedimiento nos deja una instalación de Vault con una configuración lista por defecto, con TLS habilitado, pero usando certificados digitales autofirmados.

En este enlace se obtiene el binario de instalación de Vault, según la plataforma deseada. En nuestro caso lo haremos sobre Ubuntu.

Según las indicaciones del paso anterior, procedemos con la instalación así:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install -y vault

Estos comandos son exactamente los mismos sugeridos por Hashicorp en el enlace anterior compartido.

Una vez instalado, se tiene creado estos archivos y directorios por defecto:

/etc/vault.d/vault.hcl : Archivo de configuración de Vault
/opt/vault/tls/tls.crt : Certificado autofirmado usado por Vault
/opt/vault/tls/tls.key : Llave privada del certificado.

Por ahora, no es necesario modificar nada. Pero, el servicio viene deshabilitado por defecto, por lo que tenemos que habilitarlo y levantarlo:

sudo systemctl enable --now vault

Luego, verificamos que el servicio esté corriendo y escuchando en el puerto 8200 (puerto de escucha por defecto)

# Ver estado del servicio
systemctl status vault

# Verificar el proceso de Vault
ps -ef | grep -w vault

# Verificar el puerto 8200 en escucha
sudo ss -tnlp | grep 8200

Incluso, ya es posible consultar el estado de Vault con el mismo comando vault:

vault status

Seguramente, obtendremos un error como este:

En los próximos pasos veremos cómo resolverlo.

3. Ajuste de variables

Ahora, para poder conectarnos como cliente al servidor Vault local, debemos definir una variable de entorno en /etc/environment:

sudo vim /etc/environment

…donde se agregará esto:

VAULT_SKIP_VERIFY="true"

Esto le dice al cliente Vault que no verifique la validez del certificado TLS cuando nos conectemos al servidor. Esto no es una práctica segura en entornos de Producción, pero por ahora solo estamos haciendo pruebas y además usando un certificado autofirmado, así que es aceptable lo que hicimos.

Volvemos a iniciar sesión en el host Linux para que vuelva a leer el archivo /etc/environment y luego verificamos si está definida:

echo $VAULT_SKIP_VERIFY

El cliente Vault espera que se defina en la variable de entorno VAULT_ADDR la URL de conexión al servidor Vault.

Si dicha variable no está definida, por defecto asumirá que el servidor es https://127.0.0.1:8200, el cual es un valor válido para nosotros porque el servidor Vault sí escucha en esa dirección local de nuestro equipo Linux.
Es así que ahora comprobamos que podamos consultar el estado de Vault sin problemas:

vault status

Es así como debería mostrarse ahora:

* Observar el atributo Initialized = false

4. Inicialización

Hashicorp Vault, como bóveda digital, tiene que asegurar los datos que va a almacenar. Esto lo hace a través del cifrado, debido al cual requiere el uso de una llave criptográfica maestra que protege todos los bits que escribe en disco.

Sin embargo, la llave maestra a su vez es protegida a través del Algoritmo Shamir el cual permite «dividir» una llave en varias partes. El propósito es que no sea una única persona la que posea la llave maestra, sino que sean varias personas distintas las que custodien una de las diferentes partes en las que se dividió la primera. De este modo, a la hora de descifrar el contenido de Vault, se requerirá ingresar un número mínimo de las partes de la llave para poder reconstruir la llave maestra y con ello iniciar el servicio Vault correctamente.

La inicialización de Vault consiste en preparar el espacio en el disco donde se guardarán los datos y crear una llave maestra. Esta inicialización se realiza por única vez como sigue:

vault operator init > vault-init.txt
cat vault-init.txt

La inicialización muestra un contenido sensible por única vez en pantalla. Si no se toma nota de él, no será posible volver a obtenerlo en el futuro. Es por ello que la salida del comando la he redireccionado a un archivo y luego muestro su contenido en pantalla.

Importante

Por defecto, Vault divide la llave maestra en 5 partes o llaves Shamir (conocidos también como shares o Unseal keys)
Por defecto, para poder reconstruir la llave maestra se requieren solo 3 partes diferentes cualesquiera.
Vault al iniciar como servicio está siempre en un modo Sealed o bloqueado. Esto significa que no puede acceder a su contenido porque está cifrado.
Se requiere ingresar el número mínimo de llaves Shamir para poder reconstruir la llave maestra para descifrar el contenido. Esto se conoce como Unsealing o desbloqueo.
Por cada vez que se reinicia el servicio Vault o el servidor, se requiere hacer el proceso de unsealing.
En la inicialización, Vault crea un token de root que tiene los máximos privilegios, del mismo modo como un usuario root en Linux.
Si se pierde la información de las llaves Shamir, es imposible recuperar los datos de Vault.

Ahora consultamos nuevamente el estado de Vault para observar una salida algo diferente:

Observar que Vault se reporta como inicializado (Initialized = true), pero aún bloqueado (Sealed = true)

5. Unsealing o desbloqueo

Como se sabe, Vault por defecto está bloqueado (sealed) y se necesita ingresar cualquiera 3 de las 5 llaves Shamir generadas para hacer el desbloqueo. Para ello, ejecutamos este comando 3 veces:

vault operator unseal

Por cada intento, pegar una llave Shamir diferente. Luego, consultamos el estado de Vault:

Acá se aprecia el unsealing en proceso.

Luego de ingresar las 3 llaves requeridas, al consultar el estado se muestra ahora de este modo:

Observar que ahora Vault ya no está bloqueado (Sealed = false)

A partir de este momento, Vault ya puede operar con normalidad todas sus funcionalidades completas y podemos almacenar secretos en él luego que hayamos iniciado sesión.

6. Inicio de sesión y pruebas

Vault soporta múltiples mecanismos de autenticación, tales como tokens de GitHub, LDAP (Active Directory), SAML, AWS, AppRole, etc. Pero por ahora no tenemos ningún método de autenticación configurado, por lo cual lo único que tenemos disponible para iniciar sesión es el token de root.

La forma de iniciar sesión desde línea de comandos es como se muestra debajo. Debemos pegar el token de root que obtuvimos en la inicialización de Vault.

vault login

Luego, probar algunos comandos que solo funcionan cuando ya tenemos un token de autenticación activo. Por ejemplo:

# Consultar informacion del token actual en uso
vault token lookup

# Listar motores de secretos activos
vault secrets list

# Listar metodos de autenticacion activos
vault auth list

7. Conclusión

¿Qué tan fácil te pareció esta guía? Los pasos de instalación aquí mostrados no fueron nada complicados. Sin embargo, para poder aprovechar al máximo Hashicorp Vault como una solución de bóveda digital es necesario comprender bien algunos conceptos básicos esenciales, los mismos que he detallado en este artículo.

Posteriormente compartiré más guías prácticas, con su respectivo acompañamiento teórico para poder demostrar diferentes casos de uso o problemas reales que resuelve esta genial herramienta.