Configuración
Configuración
Breadcrumbs

Backend

Uso de perfiles

Cualquiera de los servicios de Anjana puede iniciarse utilizando diferentes perfiles. Esta práctica es especialmente útil cuando se necesita ejecutar una configuración específica en momentos determinados, como cambios en el perfilado de logs o ajustes en variables que impactan el rendimiento. En la siguiente sección, se explicará cómo habilitar diferentes perfiles en diversas tecnologías; por lo tanto, ahora nos enfocaremos en cómo utilizar esos perfiles.

Por defecto, Anjana Data se configura para ejecutar el perfil 'default', el cual incluye los valores predeterminados proporcionados por Anjana. Estos valores son generalmente suficientes, a menos que se requieran configuraciones específicas de conexiones. Esta configuración se puede observar en el descriptor de servicio de cualquiera de los artefactos, donde se incluye el argumento --spring.profiles.active=default.

Es posible modificar este perfil o combinarlo con otros, utilizando una coma para separarlos, como en --spring.profiles.active=default,perfil1,perfil2. Además, se pueden ejecutar perfiles que se complementen entre sí. Es importante tener en cuenta que el orden de los perfiles configurados influye en el resultado: el último perfil especificado "gana". En caso de que existan propiedades con valores diferentes en cada perfil, se aplicará el valor del último perfil que las configure.

Distribución de configuración

Anjana puede ser configurada de diferentes modos e incluso cada servicio puede ser configurado de una manera diferente por su arquitectura de microservicios, aunque por practicidad se recomienda utilizar el mismo mecanismo para todos ellos.

Se puede configurar mediante:

  • Horus como repositorio centralizado de configuración que puede leer configuraciones de diferentes puntos como un repositorio Git, base de datos (tabla app_configuration del esquema de base de datos portuno), HashiCorp’s Vault o del sistema de archivos en el que se aloja Horus.

  • Otra forma de configuración es utilizar en cada servicio un repositorio de claves Vault (HashiCorp, AWS Secret manager, GCP Secret Manager o Azure Key Vault).

  • La última forma de configuración sería un YAML accesible directamente desde el servicio que se quiere configurar; esta última forma habilita el uso de variables de entorno en la misma máquina.

Los métodos anteriormente descritos pueden ser usados en combinación, por ejemplo utilizar Vault para la configuración de credenciales, la tabla app_configuration para configuración de Anjana y un yaml para configurar el nivel de logs.

📝Nota:

  • Si se usa Horus Vault tiene que ser mediante Horus, no puede usarse Vault de forma pura si se usa Horus.

  • Hermes no puede usar Vault de forma directa

⚠️Recomendación:

Teniendo en cuenta que la gran parte de configuración técnica corresponde a conexiones y credenciales se recomienda, por seguridad, priorizar el uso de repositorios Vault.

YAML directo

Para que un servicio pueda usar un YAML directamente se tiene que configurar el descriptor de servicio para que incluya el siguiente argumento:

--spring.config.additional-location=<path a directorio de fichero de propiedades>


Este argumento acepta ficheros concretos o directorios. Si se elige un fichero concreto, este sobreescribirá todos los valores por defecto, dejando sin valor toda configuración que no se incluya en este fichero; por ello se recomienda utilizar directorio, acabando en / la ruta elegida.

El nombre del fichero o ficheros tiene que seguir el siguiente formato: application-<profile>.yaml. El uso de perfiles se explica en el apartado anterior.

Horus como repositorio centralizado

Horus es el único que no puede usar otro Horus como proporcionador de configuración, así que para este servicio hay que elegir una de las otras dos opciones, o ambas.

Horus acepta varios tipos de repositorios para proporcionar como ya se ha comentado, pero además acepta configurar varios a la vez. Para ello se deberá establecer un orden mediante la propiedad spring.cloud.config.server.<repositorio>.order y poner un orden numérico a cada uno.

Cada servicio que vaya a hacer uso de Horus tiene que tener el siguiente argumento configurado en su descriptor de servicio: --spring.config.import=optional:configserver:http://<host de Horus>:9999/config

A continuación se detalla cómo configurar cada repositorio.

Repositorio Filesystem

Solo es necesario ajustar la carpeta donde se encuentran los ficheros de configuración de los microservicios de Anjana, es el perfil nativo de Horus.

spring:
  profiles:
    active: native
  cloud:
    config:
      server:
        native:
         search-locations:
         - file:/opt/data/config
         - file:/opt/data/config/{application}
         - file:/opt/data/config/{application}/{profile}

Repositorio Git

Se puede indicar que rama se va a usar en default-label, el resto de propiedades son genéricas de conexión a un repositorio Git

spring:
  cloud:
    config:
      server:
        git:
          uri: <usuario>@<servidor>/<repositorio>.git
          default-label: <rama>
          skipSslValidation: true
          timeout: 10
          clone-on-start: true
          force-pull: true
          searchPaths: '{application}'
          ignoreLocalSshSettings: true
          privateKey: |
            -----BEGIN RSA PRIVATE KEY-----
                       .......
            -----END RSA PRIVATE KEY-----

Repositorio Vault

Se permite la utilización de repositorios Vault mediante la herramienta de HashiCorp’s Vault

spring:
  profiles:
    active: vault
  cloud:
    config:
      server:
         vault:
            token: ******
            kv-version: 2
            host: <host de vault>
            port: 8200
            authentication: TOKEN

Para su correcta configuración con su tecnología Vault es recomendable acceder al apartado de instalación del documento “Anjana Data - Config Vault” o a la documentación oficial correspondiente.

Base de datos

Anjana tiene una comunicación nativa con la tabla app_configuration del esquema Portuno de la base de datos. Esta tabla está compuesta de las columnas:

  • Key para la propiedad a configurar

  • Value para el valor a configurar

  • Label para usar como descripción de la propiedad

  • Application para definir para qué servicio se configura la propiedad (valor NULL identifica la propiedad para todos los servicios)

  • Profile para definir el perfil asociado a la propiedad (ver que es un perfil)

Vault Encriptado

La configuración de un Vault de forma directa está solo disponible para los Tot Plugins dado que podrían no estar en la red del core de Anjana y no poder disponer de Vault a través de Horus. Por defecto viene deshabilitada esta opción, para poder habilitar cualquiera de los Vault Cloud se deberá editar el descriptor de servicio añadiendo la propiedad que habilita el Vault que se define a continuación. Para saber como configurar esta propiedad se puede seguir el formato que se explica en el apartado anterior “Uso de perfiles”.

Secrets Manager AWS

Permite guardar los parámetros sensibles de la configuración del microservicio en el servicio Secret Manager de AWS y recuperarla mediante llamada por API.

Añadir al yaml de configuración del microservicio la siguiente configuración:

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

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

Para instalar y configurar correctamente AWS Secret Manager, se necesitan conocimientos de en los servicios de AWS y seguir la documentación oficial de AWS https://docs.aws.amazon.com/es_es/secretsmanager/latest/userguide/intro.html .

Para el uso desde Anjana, se puede hacer de dos maneras:

  • Crear un usuario de IAM que tenga la política aplicada y crear variables de entorno con las credenciales:

    • AWS_ACCESS_KEY_ID

    • AWS_SECRET_ACCESS_KEY

  • O si se instala Anjana sobre una EC2 de AWS asignarle un rol con la política

Azure Key Vault

Permite guardar las propiedades sensibles de la configuración del microservicio en Azure Key Vault y recuperarla mediante llamada por api. Para más información consulte la documentación oficial: Azure Key Vault

Puntos a tener en cuenta:

  • Se debe configurar en cada microservicio que se desee conectar con el Vault, incluidos los plugin.

  • A la hora de configurar secretos, se debe tener en cuenta que Azure no permite incluir “/” en el nombre del secreto.

  • Se debe configurar las propiedades siguientes en los microservicios deseados con la conexión al Vault de Azure:

    • La configuración de spring.cloud.config.enabled debe estar deshabilitada.

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

    • El secret-key deben coincidir con el nombre del secreto creado en el Vault y se utilizará en las propiedades con el mismo nombre, de tal manera que haga referencia al secret del Vault, por ejemplo:

      • passwordDatabase: ${secretKeyName}

  • Después configurar Azure siguiendo sus manuales, se tiene que ajustar la configuración del microservicio que se quiere conectar al vault con las credenciales obtenidas. Estas propiedades se añaden al comienzo del archivo yml de configuración que se esté usando:

spring:
  cloud:
    config:
      enabled: false
    azure:
      keyvault:
        secret:
          property-source-enabled: true
          property-sources:
          - credential:
              client-id: <client ID>
              client-secret: <client key>
              endpoint: <Azure-Key-Vault-endpoint>
              case-sensitive: true
              secret-keys: <secret name1>, <secret name2>
              profile:
                tenant-id: <tenant ID>

GCP Secret Management

Permite guardar la configuración sensible en GCP Secret Management y recuperarla mediante llamada por api. Para más información consulte la documentación oficial: GCP Secret Management.

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

  • Por cada microservicio se debe crear un proyecto en GCP Secret Management

  • Los valores de las variables se leerán con el siguiente formato ${sm://<variable>} siendo sm:// el prefijo, se puede omitir con la propiedad spring.cloud.gcp.secretmanager.secret-name-prefix=sm://

Una vez realizada la configuración según los manuales de GCP, se añade el siguiente código en el archivo de configuración del microservicio que se desee.


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

También, es necesario cambiar el campo que se desee sustituir por una variable con el formato ${sm://<nombre_secret_gcp}. Un ejemplo es el siguiente:

spring:
  datasource:
  #If schema changes, change hibernate.default_schema few linew after
  url: jdbc:postgresql://rdbservice:5432/anjana?currentSchema=zeus
  username:
  password: ${sm://jdbc-password}
...

Otras formas de securizar credenciales

Variables de entorno

Se pueden usar variables de entorno para ocultar información sensible en los yamls de configuración por ejemplo.

Se crea la carpeta con el nombre del servicio /etc/systemd/system/xxxxx.service.d y dentro un archivo del tipo env.conf (root con permisos 600) de esta forma solo el microservicio tiene acceso a ese archivo env.conf.

att_2_for_165740661.png 
[Service]
Environment=<KEY>=<VALUE>
Environment=<KEY2>=<VALUE2>

En el yaml de configuración del microservicio se puede poner entre llaves y con un simbolo dolar previo ${KEY}

spring:
  datasource:
    username: anjana
    password: ${BBDD_PASSWORD}
...

Configuraciones genéricas de utilidades y performance

Todos los microservicios de Anjana tienen por defecto un tamaño de de cabeceras HTTP de 2KB, este valor puede ser modificado cambiando esta propiedad en el fichero de propiedades.

server:
  max-http-header-size: 20000

Es posible activar las estadísticas de Hibernate para visualizar la información que ofrece con la siguiente configuración.

Es importante destacar que la generación de las estadísticas puede afectar al rendimiento por lo que debe estar activa solo de forma puntual.

jpa:
  properties:
    hibernate:
      generate_statistics: true

Para Hermes, Kerno, Minerva, Portuno y Zeus se puede configurar una lista de urls que puede utilizar Swagger para hacer llamadas REST a la API en su yml. Esta configuración es opcional por lo que, en caso de no necesitar Swagger, se puede obviar. Estas urls deberán apuntar al proxy de viator para el correcto funcionamiento de Swagger, si no se incluye, Swagger genera una url válida por sí mismo.

swagger:
  server:
    url:
    - http://viatorserver/gateway
    - http://<anjana_host>/gateway
    - http://hostalias/gateway

Colector de basura: Todos los servicios que estén utilizando el jdk17 tendrán que tener el colector de basura G1 para manejar de forma más eficiente la memoria:

-XX:+UseG1GC -XX:+UseStringDeduplication

Configuración de logs

Los microservicios están configurados por defecto para que den su salida a consola estándar para que los log puedan ser gestionados por la utilidad de logs del sistema, normalmente en entornos de máquina virtual se usará syslog, rsyslog y jornalctl para consumirmos o configurar su tratamiento.

Todos ellos pueden ser configurados mediante el fichero yaml de cada uno siguiendo las prácticas estándar de Spring Boot.

Ejemplo de usos comunes:

logging:
  pattern:
  console: "%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} [HERMES] %clr(${LOG_LEVEL_PATTERN:%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:%wEx}"
  level:
    root: INFO
    com.anjana: DEBUG

Balanceo de carga

Para configurar balanceo se hace en Horus, se tiene que modificar los microservicios de Anjana que se registran en Horus (Kerno, Minerva, Hermes, Viator, Portuno, Tot, Drittesta y Zeus), cambiando el valor de eureka.client.serviceUrl.defaultZone. En el descriptor de servicio de Horus, se tiene que cambiar el valor de la variable HORUS_REPLICAS, como se describe en el apartado anterior.

Ejemplo:

eureka:
  client:
    serviceUrl:
      defaultZone: http://horusserver1:9999/eureka,http://horusserver2:9999/eureka

Lo mismo también se puede hacer pero configurado en el descriptor de servicio añadiendo una variable de entorno HORUS_REPLICAS con el listado separado por comas.

También se tiene que modificar el comando de arranque de java en cada microservicio de Anjana añadiendo en el parámetro spring.uri todas las URLs de los servidores donde Horus está escuchando. No es posible añadir autopurgado de servidores de configuración caídos en esta versión. Se hace añadiendo al comando la propiedad:

--spring.config.import=optional:configserver:http://horuserver:9999/config,optional:configserver:http://horuserver2:9999/config

Autenticación y autorización

Todo se configura en Zeus y se dispone del Yaml de ejemplo en el Nexus listo para copiar, editar y pegar lo que se necesite, incluidas descripciones de los campos.

Además las integraciones de autorización y autenticación se detallan en los documentos específicos para tal fin:

  • Anjana Data 25.1 - PROD.INS - Integración Azure

  • Anjana Data 25.1 - PROD.INS - Integración AWS

  • Anjana Data 25.1 - PROD.INS - Integración GCP

  • Anjana Data 25.1 - PROD.INS - Integración LDAP

  • Anjana Data 25.1 - PROD.INS - Integración OKTA

Notificaciones vía email

Se configuran en Hermes y se dispone y se dispone del Yaml de ejemplo en el Nexus listo para copiar, editar y pegar lo que se necesite, incluidas descripciones de los campos.


Claves de encriptación para licenciamiento Drittesta-Veltesta

El NIST recomienda usar claves de como mínimo 2048 bits, que son las que proporciona Anjana. Aún así, si el cliente lo desea, podrá generar un nuevo par de claves RSA para incrementar la seguridad de la encriptación hasta 4096 bits creando las claves de forma manual; de este modo el cliente será el creador y validador de la seguridad y unicidad de las claves. Una vez generadas, la pública la deberá proporcionar a Anjana para configurar su instalación. La privada se establecerá en el proyecto de Drittesta con la nueva propiedad del yaml anjana.privateKey teniendo en cuenta que:

  • Representa la clave privada del cliente para la comunicación entre los servicios de licencia.

  • Será una propiedad obligatoria.

  • Podrá ser generada por el cliente de la siguiente manera:

    • Con el endpoint habilitado en Drittesta para ello (clave de 2048 bits):

curl --location --request GET 'http://{{host}}:{{port}}/api/license/keys'

Donde {{host}} es la dirección de la máquina y {{port}} el puerto de Drittesta. La respuesta es un json con el siguiente formato:

{
"publicKey": clave pública,
"privateKey": clave privada
}

O bien,

En una consola UNIX ejecutar las instrucciones:

  • ssh-keygen -m PKCS8 -t rsa -b 4096

  • openssl rsa -in nombreClave -pubout

La primera genera las claves en un directorio local. Descripción de los parámetros:

  • -m indica el tipo de algoritmo que es obligatorio que sea PKCS8

  • -t indica el tipo de clave que es RSA obligatoriamente.

  • -b indica el tamaño de la clave. El cliente puede configurar el tamaño que desee. Los tamaños más comunes son 1024, 2048, 3072 o 4096 bits, siendo 4096 el tamaño máximo.

La segunda instrucción devuelve la clave pública en el formato correcto para usarse en Anjana. El parámetro “nombreClave” será el nombre de la clave que hemos dado en el paso anterior.

Tot plugins

En cada plugin existe configuración para poder registrarte en múltiples Tots y usarlo como proxy para registrarse en eureka.

totplugin.server.urls: Lista de urls de los Tot en los que el plugin se registraría.

Cada plugin puede registrar varias conexiones bajo la misma instancia, y además dispone del Yaml de ejemplo en el Nexus listo para copiar, editar y pegar lo que se necesite, incluidas descripciones de los campos.

Además de la configuración común, cada plugin tiene un documento para desplegar y configurar (con ejemplos de configuración).