Autenticar aplicaciones en Vault

Si ya probaste lo básico de la herramienta de seguridad de Hashicorp, probablemente te preguntes ahora cómo autenticar aplicaciones en Vault.

Es que Vault, como bóveda digital, está pensado no solo para ser usado por personas. El uso mayoritario y máximo beneficio se logra cuando las entidades no-humanas, como aplicaciones o máquinas, son capaces de integrarse para el consumo de secretos.

Hoy te enseñaré los fundamentos de ello con este artículo.

Pero, si eres muy nuevo en el tema, te recomiendo primero leer alguno de estos artículos previos sobre Vault:

• Qué es Hashicorp Vault
• Instalación de Hashicorp Vault
• Probando Vault en Docker
• Secretos KV en Vault

1. Introducción

1.1. Métodos de autenticación

Como comenté líneas arriba, Vault se enfoca en trabajar con dos tipos de entidades: humanas (personas) y no-humanas (aplicaciones).

Para ello, existen múltiples métodos de autenticación que son apropiados para cada uno de los tipos mencionados. Por ejemplo, aquí algunos métodos:

• userpass: Para humanos. Entidades gestionadas por Vault internamente.
• approle: Para no-humanos. Entidades gestionadas por Vault internamente.
• azure: Para no-humanos. Entidades gestionadas externamente por Azure.
• kubernetes: Para no-humanos. Entidades gestionadas externamente por Kubernetes.
• saml: Para humanos. Entidades gestionadas externamente por un IdP (Identity Provider), tal como Microsoft Entra (Azure AD), Okta, Auth0, u otros.

El método de autenticación en el que se centra este artículo es AppRole (approle).

1.2. Acerca de AppRole

AppRole es un método de autenticación dentro de HashiCorp Vault que permite a aplicaciones o máquinas autenticarse con roles definidos dentro de Vault. Es como asignar un rol específico a una aplicación, otorgándole ciertos permisos para acceder a secretos almacenados en Vault.

¿En qué casos se usa?

• Automatización: Ideal para escenarios donde necesitas que aplicaciones o scripts accedan a secretos de forma automatizada, sin intervención manual.
• Microservicios: Perfecto para autenticar microservicios que necesitan acceder a diferentes recursos protegidos por Vault.
• Orquestación: Se utiliza comúnmente en entornos de orquestación como Kubernetes para gestionar las credenciales de los servicios.

Beneficios:

• Seguridad: Permite un control granular de los permisos, asegurando que cada aplicación solo tenga acceso a los secretos necesarios.
• Flexibilidad: Se adapta a diferentes escenarios y puede ser configurado para satisfacer diversas necesidades de seguridad.
• Facilidad de uso: La configuración y gestión de los roles es relativamente sencilla.
• Integración: Se integra fácilmente con otros componentes de Vault y con diversas herramientas de orquestación.

1.3. Glosario de AppRole

A la hora de querer autenticar aplicaciones en Vault usando AppRole, te toparás con una serie de términos que es importante conocer antes de ir a la práctica. Aquí los más comunes:

• Rol: Es como un «perfil» que se asigna a una aplicación o servicio. Este perfil define los permisos específicos que esa aplicación o servicio tiene dentro de Vault. Todo Rol tiene un Role ID y puede tener mútiples Secret IDs.
• Role ID: Un identificador único asociado a un rol de AppRole. Este ID se utiliza junto con el Secret ID para autenticarse. Es un símil a un nombre de usuario, sin embargo sus valores son alfanuméricos, aleatorios y extensos (no pensados para humanos, ya verás por qué).

• Secret ID: Una credencial secreta asociada a un Role ID. Se utiliza junto con el Role ID para autenticar una solicitud. Es un símil a una contraseña.

• Token de servicio: Un token generado por Vault después de una autenticación exitosa. Este token representa la identidad del sujeto autenticado y se utiliza para realizar solicitudes a Vault.

• Política: Un conjunto de reglas que definen los permisos de un rol. Las políticas especifican qué secretos puede acceder un rol y qué acciones puede realizar sobre ellos.

Otros conceptos indirectamente relacionados que también son clave tener claros:

• Autenticación: El proceso de verificar la identidad de un sujeto (usuario, aplicación, servicio) antes de conceder acceso a recursos protegidos.
• Autorización: El proceso de determinar qué acciones puede realizar un sujeto autenticado sobre los recursos a los que tiene acceso.

1.4. Flujo de trabajo para autenticar aplicaciones en Vault

Este flujo que explicaré a continuación es usualmente el mismo en todos los métodos de autenticación, pero lo explico aquí para el caso particular de AppRole:

La autenticación en Vault con AppRole es un proceso de dos fases que garantiza un acceso seguro y controlado a los secretos almacenados.

Primera Fase: Obtención del Token de Servicio

1. Solicitud de Credenciales: Una aplicación solicita un Role ID y un Secret ID a un administrador de Vault. Estos identificadores están asociados a un rol específico que define los permisos de la aplicación.
2. Autenticación: La aplicación envía una solicitud de autenticación a Vault, proporcionando el Role ID y el Secret ID.
3. Generación del Token: Si las credenciales son válidas, Vault genera un token de servicio. Este token contiene información clave, incluyendo:
   • Identidad del sujeto: Representa a la aplicación que se ha autenticado.
   • Políticas: Un conjunto de reglas que definen qué acciones puede realizar la aplicación en Vault. Estas políticas están vinculadas al rol al que pertenece el Role ID.

Segunda Fase: Utilización del Token de Servicio

1. Incorporación del Token: La aplicación incluye el token de servicio en el encabezado de todas las solicitudes posteriores a Vault.
2. Validación y Autorización: Vault valida el token y extrae las políticas asociadas. Luego, compara las acciones solicitadas por la aplicación con las permitidas por las políticas.
   • Si la aplicación intenta realizar una acción que no está permitida por las políticas, la solicitud será denegada.
   • Si la aplicación tiene los permisos necesarios, Vault procesará la solicitud.

El Rol de las Políticas en la Autorización

• Definición de Permisos: Las políticas son el mecanismo principal para controlar el acceso a los secretos en Vault. Definen qué secretos puede leer, escribir o modificar una aplicación.
• Vinculación al Token: Cuando se genera un token de servicio, se le asocian las políticas del rol correspondiente. Esto significa que el token lleva consigo la información necesaria para autorizar todas las solicitudes posteriores.
• Flexibilidad: Las políticas se pueden definir de forma granular, permitiendo un control preciso sobre el acceso a los secretos. Por ejemplo, se puede crear una política que permita a una aplicación leer solo un subconjunto de secretos.

1.5. Ejemplo de flujo de trabajo

Imagina una aplicación de microservicios que necesita acceder a las credenciales de una base de datos y a una API externa.

1. Se crean dos roles en Vault: db_reader y api_caller.
2. A cada rol se le asigna una política que define los permisos específicos (por ejemplo, leer la contraseña de la base de datos para db_reader y llamar a la API externa para api_caller).
3. Los microservicios obtienen tokens de servicio asociados a los roles correspondientes.
4. Cuando un microservicio necesita acceder a la base de datos, utiliza su token para realizar una solicitud a Vault. Vault verifica el token y las políticas asociadas, y si la acción está permitida, devuelve la contraseña de la base de datos.

2. Configuración

Ya fue suficiente teoría por ahora. Es así que para autenticar aplicaciones en Vault tenemos que realizar esta secuencia de pasos:

2.1. Habilitar el método de autenticación

Una vez que estés autenticado en Vault con el token de root, o con permisos equivalentes, procedes de este modo:

vault auth enable approle

Esto activa el método de autenticación montado en la ruta por defecto, que lleva el mismo nombre «approle».

2.2. Crear políticas

Estrictamente hablando, este paso puede no ser necesario, siempre y cuando ya existan políticas creadas con anterioridad. Pero asumiendo que empezamos de cero, crearé por lo menos una política de Vault bastante sencilla.

Primero, creo el archivo y lo edito:

touch secrets-policy.hcl

vi secrets-policy.hcl

Como contenido pegas esta política en lenguaje HCL:

# Permisos de solo lectura en la ruta "secretos/" y todo lo que hay dentro
path "secretos/*" {
  capabilities = ["read", "list"]
}

• Importante: Esta política asume que ya existe una ruta «secretos/», la cual se supone debe ser tipo KV o KV v2. Además, la política define que el acceso brindado permitirá leer y listar secretos dentro de la ruta indicada.

Ahora, crea la política llamada secrets-policy (el nombre es arbitrario) a partir del archivo HCL recién editado:

vault policy write secrets-policy secrets-policy.hcl

2.3. Crear rol de AppRole

Voy a crear un rol llamado mi-app-demo (porque la asociaré a una aplicación demo) que haga que los tokens creados a partir de éste tengan asociada la política secretes-policy. Además, dichos tokens tendrán una duración por defecto de 1 hora y máxima de 4 horas.

vault write auth/approle/role/mi-app-demo \
  token_policies=secrets-policy \
  token_ttl=1h \
  token_max_ttl=4h

2.4. Obtener el Role ID

Todo rol de AppRole tiene un Role ID único y este se obtiene del siguiente modo:

vault read auth/approle/role/mi-app-demo/role-id

La salida del comando debería lucir así:

Para autenticar aplicaciones en Vault usarás este Role ID como si se tratase del usuario de autenticación.

2.5. Generar un Secret ID

Los Secret ID se crean a demanda y solo se ven en pantalla por vez única cuando se crean. Además, puede crearse múltiples Secret IDs, todos asociados al mismo rol de AppRole (ligados al mismo Role ID).

Para crear un Secret ID se usa este comando:

vault write -f auth/approle/role/mi-app-demo/secret-id

La salida del comando debería lucir así:

El Secret ID lo usarán las aplicaciones como si se tratase de una contraseña de autenticación.

3. Prueba de autenticación y consumo de secretos

Ahora que ya se creó un Rol de AppRole, se obtuvo su Role ID y se generó un Secret ID, ya se tiene todas las piezas completas para que una aplicación lo use. ¡Ya estás listo para autenticar aplicaciones en Vault!

Pero, ahora, ¿qué aplicación se puede probar para que se autentique con Vault usando AppRole? Pues, se requiere alguna de estas opciones:

1. Una aplicación que sepa hablar con las APIs de Vault, que maneje el método de autenticación AppRole correctamente, así como también el uso de tokens y el consumo de secretos.
2. Usar un aplicativo intermediario que realice todo lo del punto 1 y facilite a la aplicación los secretos ya servidos (en un archivo o variable, por ejemplo). Esto es a través del Agente de Vault y se explicará en otro artículo posterior.

Para el punto 1 se me ocurre algunas aplicaciones de ejemplo:

• Jenkins con el plugin de Hashicorp Vault – Tiene integración nativa con Vault y AppRole, así como también la lectura de secretos KV.
• GitHub Actions con hashicorp/vault-action – Este es un Action que, de modo similar al anterior en Jenkins, permite autenticarse y consumir secretos de Vault.

No son los únicos ejemplos, pero son los más comunes y fáciles de explicar. Sin embargo, hacerlo en este artículo no será posible por ahora. Dado que el tema se extiende mucho para este post, prometo que haré publicaciones dedicadas para cada uno de ambos casos.

Entonces, ¿cómo vas a realizar la prueba?: Por ahora, usando la línea de comandos de Vault y también a través de APIs usando el comando curl.

3.1. Autenticación con Vault CLI

En una terminal de comandos, me aseguro de definir las variables de entorno necesarias para conectar con Vault y luego me autentico con los datos de autenticación creados anteriormente:

export VAULT_ADDR=http://localhost:8200

vault write auth/approle/login \
  role_id=e59b2fb5-0752-71a0-61d5-5ae9ceaa0d29 \
  secret_id=030cec68-2b84-5a75-8432-066a415b8488

Así luce la cosa:

3.2. Autenticación vía API con curl

Primero, creo un archivo JSON con las credenciales:

touch data.json
vi data.json

Pego el siguiente contenido dentro:

{
  "role_id": "e59b2fb5-0752-71a0-61d5-5ae9ceaa0d29",
  "secret_id": "030cec68-2b84-5a75-8432-066a415b8488"
}

Uso el comando curl apuntando hacia la URL del servidor Vault y usando el archivo de credenciales con el método POST, como sigue:

curl -s -X POST -d @data.json http://localhost:8200/v1/auth/approle/login

La salida luce no muy fácil de leer:

Si instalas el utilitario jq se puede formatear la salida JSON y hacerse más fácil de endender, así:

curl -s -X POST -d @data.json http://localhost:8200/v1/auth/approle/login | jq

Ahora sí luce mucho mejor:

• Importante: Ahora que ya se obtuvo un token de servicio (vía CLI y/o API), ya se puede usar dicho token en las llamadas API siguientes para hacer operaciones en Vault, como por ejemplo consumir secretos.

3.3. Consumo de secretos con Vault CLI

Dado que ya tengo el token de servicio luego de autenticarme con el Role ID y Secret ID, ya debo ser capaz de consumir secretos. Por ejemplo así:

export VAULT_ADDR=http://localhost:8200
export VAULT_TOKEN=hvs.CAESIAJaxEJMvOAJYwzefQy4IiIt6p-scIjwEAhqkKmArI7AGh4KHGh2cy5LMlVsbExEREZ4bXhxbnE1c0FLeDFmVUc

vault kv get secretos/mysql/dev

Aquí la demostración de cómo luce la lectura de un secreto:

3.4. Consumo de secretos vía API con curl

Vía APIs, se hace así:

export token=hvs.CAESIAJaxEJMvOAJYwzefQy4IiIt6p-scIjwEAhqkKmArI7AGh4KHGh2cy5LMlVsbExEREZ4bXhxbnE1c0FLeDFmVUc

curl -sH "X-Vault-Token: $token" https://localhost:8200/v1/secretos/data/mysql/dev | jq

Así luce el secreto consumido:

• Importante: Estos ejemplos de consumo de secretos asumen que ya existe una ruta KV v2 llamada «secretos/» y que dentro hay un secreto en la ruta secretos/mysql/dev

4. Cierre

Como ya voy haciendo costumbre, en algunos temas requiero escribir artículos un poquito extensos para buscar una mejor comprensión de los lectores.

Hoy he explicado sobre los diferentes métodos de autenticación existentes y he profundizado en AppRole, el cual es más apropiado para autenticar aplicaciones en Vault.

También, indiqué los conceptos base asociados a AppRole y cómo es el flujo de trabajo de autenticación, autorización y consumo de secretos. Finalmente, hice una simulación básica de cómo una aplicación lleva a cabo ese flujo, tanto a través de Vault CLI, como también a través de llamadas API.

Como lo prometí, en otros artículos posteriores demostraré cómo ejecutar estos mismos flujos desde Jenkins, GitHub Actions y también con el uso del Agent Vault integrado con WordPress.

Si te interesa saber más de estos temas y te gusta lo que publico, compártelo y mantente conectado conmigo para nuevo material en un futuro cercano.