Instalando HashiCorp Vault para la Gestión de Secretos

Jul 11, 2025 - 8 min read - 1203 words

Wilzon Liscano Galindo

Founder of CodeDesignPlus

En cualquier arquitectura de software, la gestión de secretos (contraseñas, claves de API, certificados) es una de las tareas más críticas y a menudo, peor manejadas. “Hardcodear” secretos en el código o en archivos de configuración dentro de repositorios de Git es un anti-patrón de seguridad garrafal.

La solución profesional es un gestor de secretos centralizado. Para nuestro ecosistema, utilizaremos el estándar de la industria: HashiCorp Vault.

El Rol de Vault en CodeDesignPlus

Vault es el cerebro de nuestra configuración. Al arrancar, cualquier microservicio construido con el SDK de CodeDesignPlus se conectará automáticamente a Vault, obtendrá los secretos que le corresponden y los usará para sobrescribir dinámicamente cualquier valor presente en sus archivos appsettings.json. Esto nos da una flexibilidad y seguridad inmensas: podemos rotar contraseñas o actualizar configuraciones en un solo lugar (Vault) sin necesidad de redeployar nuestros microservicios.

En esta guía, desplegaremos Vault en modo de desarrollo y realizaremos la configuración inicial para preparar el terreno para nuestros microservicios.

Parte 1: Desplegando Vault con Helm

1. Añadir el Repositorio de Helm de HashiCorp Primero, le enseñamos a Helm dónde encontrar los charts oficiales de HashiCorp.

   helm repo add hashicorp https://helm.releases.hashicorp.com

   

2. Crear y Etiquetar el Namespace Desplegaremos Vault en su propio namespace dedicado y lo etiquetaremos para la inyección del sidecar de Istio, lo que nos permitirá aplicar políticas de seguridad mTLS en el futuro.

   kubectl create namespace vault
   kubectl label namespace vault istio-injection=enabled

   

3. Preparar el Archivo de Configuración (values.yaml) Para instalar Vault en modo de desarrollo con la UI habilitada, creamos un archivo values.yaml:

   values.yaml

   global:
     enabled: true
     resources:
       requests:
         memory: 256Mi
         cpu: 250m
       limits:
         memory: 256Mi
         cpu: 250m
   
   server:
     dev:
       enabled: true
       devRootToken: "ANGq0*B2acD1n5%F"
     service:
       enabled: true
       type: ClusterIP
       port: 8200
       targetPort: 8200
   ui:
     enabled: true
     serviceType: ClusterIP
     externalPort: 8200
   
   injector:
     enabled: "false"

   • server.dev.enabled: true: Inicia Vault en un modo de desarrollo simple, con un solo nodo y almacenamiento en memoria (ideal para pruebas, nunca para producción).
   • ui.enabled: true: Habilita la interfaz web de Vault.
   • serviceType: "ClusterIP": Expone la UI con un servicio interno, que luego haremos accesible a través de nuestro Gateway de Istio.
   • server.dev.devRootToken: Establece el token raíz a un valor conocido para facilitar el acceso en desarrollo.

4. Instalar Vault Usamos Helm para desplegar Vault con nuestra configuración personalizada.

   helm install vault hashicorp/vault -n vault --values values.yaml

   

5. Verificar el Despliegue en Lens En Lens, bajo “Helm > Releases”, vemos la nueva release vault.

   

   Y en “Workloads > Pods”, encontramos el pod vault-0 corriendo en el namespace vault.

   

Parte 2: Exponiendo la UI y Configuración Inicial

1. Crear el VirtualService para la UI de Vault Creamos un archivo network.yaml para indicarle a Istio cómo enrutar el tráfico hacia la UI de Vault.

   network.yaml

   apiVersion: networking.istio.io/v1
   kind: VirtualService
   metadata:
     name: vault-virtualservice
     namespace: vault
   spec:
     hosts:
     - vault.codedesignplus.app
     gateways:
     - istio-ingress/istio-gateway
     http:
     - route:
       - destination:
           host: vault-ui.vault.svc.cluster.local
           port:
             number: 8200

   Aplicamos el manifiesto:

   kubectl apply -f .\network.yaml

   

2. Configurar el Acceso Local (Archivo hosts) Añadimos la entrada temporal a nuestro archivo hosts para que nuestro navegador pueda encontrar vault.codedesignplus.app.

   192.168.0.30    vault.codedesignplus.app

   

3. Iniciar Sesión por Primera Vez Abrimos el navegador en https://vault.codedesignplus.app. Para iniciar sesión, usamos el token que definimos en nuestro values.yaml.

   

   ¡Estamos dentro! Ya podemos ver el panel principal de Vault.

   

4. Configurar la CLI de Vault Para configuraciones avanzadas, usaremos la CLI. Primero, iniciamos sesión desde nuestra terminal especificando el token que definimos en el values.yaml.

   $env:VAULT_ADDR = "https://vault.codedesignplus.app"
   vault login token=<token>

   

Parte 3: Configuración de Motores y Autenticación

Ahora prepararemos Vault para que nuestros microservicios puedan usarlo.

1. Habilitar el Método de Autenticación AppRole AppRole es uno de los métodos para que las máquinas (nuestros microservicios o la CLI) se autentiquen en Vault. Sin embargo, en un ambiente de producción, deberíamos usar un método más robusto como Kubernetes o OIDC. Para este tutorial, habilitamos AppRole para simplificar.

   vault auth enable approle

   

2. Habilitar los Motores de Secretos Habilitaremos varios “motores” que Vault usará para gestionar diferentes tipos de secretos.

   vault secrets enable -path=inventory-keyvalue kv-v2
   vault secrets enable -path=inventory-database database
   vault secrets enable -path=inventory-rabbitmq rabbitmq
   vault secrets enable -path=inventory-transit transit

   

   En la UI, bajo “Secrets Engines”, ahora podemos ver todos los motores que hemos habilitado.

   

   Un Vistazo a Nuestros Motores de Secretos

   Cada “motor” en Vault está especializado en gestionar un tipo diferente de secreto. Aquí está el propósito de los que acabamos de habilitar:

   • kv-v2 (Key-Value Versionado): Este es el caballo de batalla para secretos estáticos. Lo usaremos para almacenar pares de clave-valor como cadenas de conexión, claves de API de terceros, etc. Su principal ventaja es que mantiene un historial de versiones de cada secreto, permitiéndonos revertir a una versión anterior si es necesario. Lo hemos montado en inventory-keyvalue/.

   • database: Este motor es increíblemente potente. No almacena contraseñas estáticas, sino que se conecta a tu base de datos y genera credenciales dinámicas y de corta duración bajo demanda. Cada vez que un microservicio necesita acceder a la base de datos, puede solicitar un usuario y contraseña únicos que expiran después de un tiempo. Esto mejora drásticamente la seguridad. Lo usaremos para gestionar el acceso a MongoDB Atlas y lo montamos en inventory-database/.

   • rabbitmq: Similar al motor de base de datos, este se conecta a nuestro clúster de RabbitMQ y puede generar usuarios y permisos dinámicos para que los microservicios publiquen o consuman mensajes de colas específicas. Lo montamos en inventory-rabbitmq/.

   • transit: Este es el motor de “Cifrado como Servicio” (Encryption as a Service). Permite que nuestras aplicaciones envíen datos a Vault para ser cifrados, sin que la aplicación tenga que manejar las claves de cifrado directamente. Es ideal para proteger datos sensibles (como números de tarjetas de crédito o información personal) antes de guardarlos en la base de datos. Lo montamos en inventory-transit/.

3. Crear una Política de Acceso Las políticas definen qué puede hacer una identidad en Vault. Crearemos una política de “acceso total” para nuestro entorno de desarrollo. Creamos un archivo full-access.hcl:

   full-access.hcl

   path "*" {
     capabilities = ["create", "read", "update", "delete", "list"]
   }

   Y la aplicamos con la CLI:

   vault policy write full-access .\full-access.hcl

   

   Podemos verificar la política en la UI, bajo “Policies”.

   

4. Crear un Rol de AppRole y Obtener Credenciales Ahora, creamos un rol que une la política de full-access con el método de autenticación AppRole. Luego generamos las credenciales (RoleID y SecretID) que podremos usar en el CLI para llevar a cabo las configuraciones de nuestros microservicios.

   vault write auth/approle/role/inventory-approle policies="full-access"
   vault read auth/approle/role/inventory-approle/role-id
   vault write -f auth/approle/role/inventory-approle/secret-id

   

   Podemos verificar la creación del método approle en la UI, bajo “Access > Authentication Methods”.

   

5. Probar el Login con AppRole Para asegurarnos de que todo funciona, podemos hacer un login de prueba usando las credenciales que acabamos de generar.

   vault write auth/approle/login role_id=TU_ROLE_ID secret_id=TU_SECRET_ID

   

6. Crear un Secreto de Ejemplo Finalmente, creamos nuestro primer secreto en el motor inventory-keyvalue.

   vault kv put -mount=inventory-keyvalue ms-my-microservice `
       "MySecret1=Value1" `
       "MySecret2=Value2"

   

   Podemos ver el secreto creado en la UI, navegando al motor inventory-keyvalue.

   

Conclusión y Próximos Pasos

¡Has desplegado y configurado exitosamente HashiCorp Vault! Ahora tienes un almacén centralizado y seguro para toda la configuración de tu ecosistema.

Entorno de Desarrollo vs. Producción

Recuerda, esta instalación está en modo de desarrollo. Es perfecta para aprender y construir, pero no es resiliente ni está preparada para producción. En una futura serie de artículos avanzados, exploraremos cómo desplegar Vault en modo de alta disponibilidad (HA), con persistencia de datos y un proceso de “unseal” seguro.

En los próximos artículos, cuando empecemos a desplegar el ecosistema base de CodeDesignPlus, verás cómo nuestros microservicios utilizan el método de autenticación Kubernetes en un entorno de producción para conectarse a Vault y obtener los secretos que definiremos para cada uno, como las cadenas de conexión a la base de datos o las claves de API. Sin embargo, continuaremos con el método de autenticación AppRole para el CLI y Token para simplificar el proceso de configuración inicial y para la conexión de los microservicios en desarrollo.

Si deseas profundizar en el uso de la CLI y los diferentes motores de Vault, puedes consultar nuestra guía: Administrando Vault: Guía Avanzada.

Tags:

• Vault
• HashiCorp
• Secrets Management
• Kubernetes
• Helm
• DevSecOps
• Visual

Desplegando RabbitMQ con el Operator en Kubernetes

Centralizando la Observabilidad con OpenTelemetry Collector