Configuración
Breadcrumbs

Vaults

Configuración de HashiCorp Vault

Para que la configuración se recupere del HashiCorp Vault se requiere únicamente la configuración del módulo de Horus.

Credenciales requeridas

Para la configuración correcta, se necesitará el token correspondiente al usuario y establecerlo en la variable de entorno VAULT_HASHICORP_TOKEN en el fichero de /etc/systemd/system/horus.service.d/env.conf.

Para conseguir ese token habrá 2 maneras:

Mediante el token propio del usuario. A partir de nuestro usuario podremos ir a Vault y una vez logados nos aparecerá la opción de copiar el token.

att_2_for_171934259.png

Mediante comando de línea. Desde este comando podremos crear un token sin necesidad de crear usuario. El comando es vault create token. A continuación se adjunta un ejemplo, pudiendo configurar a nuestro gusto los parámetros (más información en su documentación):

att_1_for_171934259.png

Cosas a tener en cuenta:

  • Al reiniciar el entorno HashiCorp se queda bloqueado, y para desbloquearlo se necesitan meter 3 keys.

  • Los token tienen un límite de validez como máximo de 10h (de momento)

Configuración necesaria en el microservicio

Para la configuración del servicio se tiene que establecer esta configuración en el YAML correspondiente:

spring.cloud.config:
server:
vault:
order: 1
host: 10.150.100.249
token: ${VAULT_HASHICORP_TOKEN}
kv-version: 2
authentication: TOKEN
backend: kv


Cuya significado de las propiedades son:

  • order: En caso de haber más de un origen de propiedades se establecerá esta propiedad estableciendo la prioridad respecto a otros.

  • host: Servidor en el que está alojado Vault. Por defecto: 0.0.0.0

  • port: Puerto del servidor en el que está alojado Vault: Por defecto: 8200

  • token: Token de autorización

  • kv-version: versión del key-pair de Vault

  • authentication: Vault permite varios tipo de autenticación , en este caso hemos optado por token. Para más información en su documentación

  • backend: prefijo de la carpeta que están alojadas las propiedades. Por defecto: secret

Además al momento de arrancar el servicio se tiene que hacer añadiendo el perfil activo de vault.

Cosas a tener en cuenta:

A pesar de que en el entorno actual se instale vault para utilizar de forma local, el cluster donde se instala parece ser externo y no se puede llamar desde edusa a localhost, tiene que ser con su ip.

Configuración de AWS Secret Manager

Para que la configuración se recupere del AWS Secret Manager es necesario configurar cada microservicio.

Credenciales requeridas

Configuración necesaria en el microservicio

Dentro del bootstrap del microservicio se ha incluido la siguiente configuración :

aws:
  secretsmanager:
    enabled: true
    region: eu-central-1

En el comando de arranque del microservicio hay que quitar las propiedades:

--spring.config.import=configserver:http://edusaserver:8888
--spring.cloud.config.failFast=true


Dentro del AWS Secret Manager los secretos se guardan con el prefijo ‘/secret’, acompañado del nombre del microservicio y del perfil de spring separado por ‘_’ (configuración por defecto de AWS Secret Manager).

Por ejemplo para configurar kerno con el profile default el secreto será /secret/kerno_default y su valor serán las propiedades que se requieran para que funcione.

Configuración de Vault de GCP

A continuación se va a detallar cómo configurar el microservicio para que llame al vault de gcp para recoger las propiedades.

Credenciales requeridas

Configuración necesaria en el microservicio

Dentro del fichero de configuración del microservicio se tiene que incluir lo siguiente:

spring.cloud.gcp:
 core:
   enabled: true
 secretmanager:
   enabled: true
   project-id: 623609426553 # Código del proyecto gcp secret management
   credentials:
     location: file:*******.json # Fichero que contiene las credenciales gcp

En el comando de arranque del microservicio hay que quitar las propiedades:

--spring.config.import=configserver:http://edusaserver:8888
--spring.cloud.config.failFast=true


Para cada uno de los microservicios se debe crear un único proyecto de gcp secret management. En esta ocasión no depende del perfil activo ni el nombre de la aplicación.

Para obtener las propiedades se tiene que añadir el prefijo de ‘sm://’

Configuración de Vault de Azure

A continuación se va a detallar cómo configurar el microservicio para que llame al vault de azure para recoger las propiedades.

Credenciales requeridas

Configuración necesaria en el microservicio