Vaults

Este documento detalla cómo configurar cada uno de los repositorios de secretos (Vaults) soportados por Anjana Data Platform: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager y Azure Key Vault.

⚠️ Importante, quién puede conectarse directamente a un Vault:

• Los servicios core de Anjana Data (Kerno, Minerva, Hermes, Zeus, Viator, Portuno, Drittesta, etc.) obtienen siempre su configuración a través de Horus. Es Horus quien se conecta al Vault (HashiCorp, AWS o GCP) según el repositorio configurado; los servicios core nunca se conectan a un Vault de forma directa.

• Los Tot Plugins son los únicos componentes que pueden conectarse de forma directa a un Vault o Secret Manager, sin pasar por Horus, dado que pueden no estar desplegados en la red del core de Anjana. Las secciones de AWS Secrets Manager, GCP Secret Manager y Azure Key Vault de este documento describen esa conexión directa y son exclusivas para plugins.

La sección de HashiCorp Vault describe la configuración de Horus como repositorio centralizado y aplica a todos los servicios core.

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.

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):

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:

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 horus 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.

⚠️ Esta configuración de conexión directa es exclusiva de Tot Plugins. Los servicios core siempre obtienen su configuración a través de Horus (ver sección de HashiCorp Vault).

Credenciales requeridas

Para conectar el plugin con AWS Secrets Manager existen dos vías:

• Crear un usuario de IAM con la política de acceso a Secrets Manager aplicada, y configurar sus credenciales como variables de entorno en el descriptor de servicio del plugin: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY

• O, si el plugin se despliega sobre una instancia EC2 de AWS, asignar a dicha instancia un rol de IAM con la política de Secrets Manager aplicada (opción recomendada: evita gestionar claves estáticas).

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://horusserver: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.

⚠️ Esta configuración de conexión directa es exclusiva de Tot Plugins. Los servicios core siempre obtienen su configuración a través de Horus (ver sección de HashiCorp Vault).

Credenciales requeridas

Antes de configurar el plugin es necesario:

• Disponer de un proyecto de GCP con la API de Secret Manager habilitada. Se recomienda crear un proyecto de GCP Secret Manager por cada plugin.

• Generar un fichero de credenciales de una cuenta de servicio (Service Account key) en formato JSON, con permisos de lectura sobre Secret Manager, y depositarlo en el servidor donde se ejecuta el plugin.

• Anotar el project-id del proyecto de GCP, necesario para la configuración del plugin.

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: <código del proyecto GCP Secret Manager> # 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://horusserver: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://'

Este prefijo puede omitirse configurando la propiedad spring.cloud.gcp.secretmanager.secret-name-prefix=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.

⚠️ Esta configuración de conexión directa es exclusiva de Tot Plugins. Los servicios core siempre obtienen su configuración a través de Horus (ver sección de HashiCorp Vault).

Credenciales requeridas

Antes de configurar el plugin es necesario disponer de:

• Un Azure Key Vault con los secretos que necesita el plugin ya creados.

• Un registro de aplicación (App registration) en Azure AD con permisos de lectura sobre el Key Vault (mediante Access Policy o rol RBAC), del que se obtienen: client-id, client-secret, tenant-id

• El endpoint del Key Vault (URL proporcionada por Azure al crear el recurso).

Configuración necesaria en el microservicio

Puntos a tener en cuenta:

• Se debe configurar en cada plugin que se desee conectar con el Vault.

• Azure no permite incluir "/" en el nombre del secreto.

• La propiedad spring.cloud.config.enabled debe estar deshabilitada.

• La propiedad secret-keys indica qué secretos del Vault se quieren usar (si son varios, lista separada por comas); si no se especifica, se traerán todos los secretos del Vault.

• El valor de secret-keys debe coincidir con el nombre del secreto creado en el Vault, referenciado en las propiedades con ese mismo nombre, por ejemplo: passwordDatabase: ${secretKeyName}.

spring:
  cloud:
    config:
      enabled: false
    azure:
      keyvault:
        secret:
          property-source-enabled: true
          property-sources:
          - credential:
              client-id: <client ID>
              client-secret: <client secret>
              endpoint: <endpoint del Azure Key Vault>
              case-sensitive: true
              secret-keys: <nombre secreto 1>, <nombre secreto 2>
              profile:
                tenant-id: <tenant ID>