Configuración de Secrets Manager

Esta sección recoge la información necesaria para preparar el gestor de secretos (Secrets Manager) que alimenta a Anjana Data Platform cuando el despliegue se realiza con Anjana Installer. Describe cuántos secretos deben crearse, cómo deben nombrarse, qué propiedades contiene cada uno y qué significa cada una de ellas.

El gestor de secretos equivalen a los ficheros de configuración en texto plano en despliegues en Ansible : las credenciales de persistencias, licencia y repositorios, así como los ajustes específicos de cada microservicio y de cada plugin, se almacenan como secretos y se recuperan en tiempo de arranque. En despliegues Onprem es el backend recomendado.

1. Cuántos secretos hay que crear

El número de secretos depende de cuánta configuración específica necesite el entorno. Solo el primero es obligatorio; el resto se crean únicamente cuando hace falta sobrescribir la configuración por defecto de un componente concreto.

Un entorno mínimo funciona con un único secreto. Un entorno con SSO en Zeus, notificaciones en Hermes y dos plugins de extracción tendría cuatro secretos adicionales, cinco en total.

2. Convención de nombres y prefijo

Todos los secretos de un mismo entorno cuelgan de un prefijo común, que aísla ese entorno del resto. El nombre de cada secreto se compone del prefijo, el nombre de la aplicación y el perfil de Spring separados por guion bajo, y termina en barra:

{prefijo}/{nombre-de-la-aplicacion}_{perfil}/

El prefijo es la suma de /secret + /{env} siendo env el entorno en cuestión.

El perfil utilizado por todos los componentes de la plataforma es siempre default. Por tanto:

2.1 Ejemplo de un entorno real

Listado de secretos de un entorno de demostración con prefijo /secret/demo, tal y como se ven en la consola de AWS Secrets Manager:

/secret/demo/application_default/
/secret/demo/tot-plugin-jdbc_default/
/secret/demo/tot-plugin-jdbc-denodo_default/
/secret/demo/tot-plugin-jdbc-sqlserver_default/
/secret/demo/tot-plugin-ldap_default/

Este entorno ilustra el caso más habitual: el secreto de aplicación más un secreto por cada plugin desplegado, sin ningún secreto por microservicio, porque ninguno necesita sobrescribir su configuración por defecto.

El nombre de cada plugin se escribe en kebab-case (tot-plugin-jdbc-denodo), y el guion bajo aparece únicamente como separador del perfil. Conviene no confundirlo con el nombre del directorio de configuración local del plugin en el servidor, que sí utiliza guiones bajos (/{installFolder}/data/config/tot_plugin_jdbc/).

El prefijo se declara en dos sitios que deben coincidir: el parámetro secretsBackend.awsSecretsPrefix del instalador (configurable desde el wizard, sección Secrets Backend, o en installation.yaml) y la variable de entorno HORUS_SM_PREFIX del entorno. El valor por defecto es /secret/dev.

secretsBackend:
  installerBackend: AWS_SECRETS_MANAGER
  awsRegion: eu-central-1
  awsSecretsPrefix: /secret/pro

3. Formato del contenido de un secreto

Cada secreto es un único documento JSON plano (blob): un objeto sin anidamiento, donde cada clave es una propiedad y cada valor su contenido en formato texto. No se admiten objetos ni arrays anidados.

Conviven dos familias de claves:

• Claves de infraestructura, en mayúsculas con guion bajo (DB_PASS, MONGO_URI, S3_ACCESS_KEY…). Tienen un mapeo fijo a la configuración interna del instalador y de la plataforma. Solo son válidas las claves recogidas en la tabla del apartado 4.

• Propiedades de configuración, en notación de punto (app.base-url, anjana.messaging.google-chat.webhook-url…). Se inyectan como propiedades de Spring y admiten cualquier propiedad soportada por el componente.

3.1 Equivalencia entre YAML y propiedad del Secrets Manager

La documentación de configuración de la plataforma expresa históricamente los ajustes en YAML. Para trasladar cualquiera de esas configuraciones al gestor de secretos basta con aplanar la ruta del YAML, uniendo cada nivel con un punto y respetando la escritura exacta de cada tramo. El valor se copia tal cual, como cadena de texto.

En YAML:

anjana:
  messaging:
    google-chat:
      webhook-url: https://chat.googleapis.com/v1/spaces/...

La misma configuración en el gestor de secretos:

{
  "anjana.messaging.google-chat.webhook-url": "https://chat.googleapis.com/v1/spaces/..."
}

Para las propiedades que en YAML son listas, se emplea la notación indexada habitual de Spring: clave[0], clave[1], etc.

4. Secreto de aplicación

Es el único secreto obligatorio. Contiene la configuración compartida por todos los microservicios de la plataforma y las credenciales que el propio instalador necesita para arrancar. Se crea con el nombre {prefijo}/application_default/.

4.1 Base de datos relacional (PostgreSQL)

4.2 Base de datos documental (MongoDB / DocumentDB)

4.3 Motor de indexación (Solr)

4.4 Almacenamiento de objetos (S3 / SeaweedFS)

4.5 Mensajería (RabbitMQ)

4.6 Caché (Valkey)

4.7 Repositorio de artefactos (Nexus)

4.8 Licencia

4.9 Credenciales de arranque del instalador

4.10 Propiedades de plataforma

Además de las claves de infraestructura anteriores, el secreto de aplicación admite propiedades de configuración en notación de punto, comunes a todos los microservicios.

4.11 Ejemplo completo anonimizado

Contenido de referencia del secreto {prefijo}/application_default/. Todos los valores son ficticios y deben sustituirse por los del entorno.

{
  "DB_URL": "anjana-pro.rds.eu-central-1.amazonaws.com:5432",
  "DB_USER": "anjana_app",
  "DB_PASS": "<contrasena-postgresql>",

  "MONGO_URI": "mongodb://anjana_app:<contrasena-mongodb>@anjana-pro-docdb.cluster.eu-central-1.docdb.amazonaws.com:27017/anjana?tls=true&replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false",

  "INDEX_URL": "solr.pro.svc.cluster.local:8983/solr",
  "INDEX_USER": "anjana",
  "INDEX_PASS": "<contrasena-solr>",

  "S3_TYPE": "aws_s3",
  "S3_REGION": "eu-central-1",
  "S3_ACCESS_KEY": "<access-key-id>",
  "S3_SECRET_KEY": "<secret-access-key>",
  "S3_BUCKET_CDN": "cdn-pro-anjana",
  "S3_BUCKET_DSA": "dsa-pro-anjana",
  "S3_BUCKET_IMPORTS": "imports-pro-anjana",
  "S3_BUCKET_TEXTAREA": "textarea-pro-anjana",
  "S3_BUCKET_WORKFLOWS": "workflows-pro-anjana",

  "RABBITMQ_HOST": "rabbitmq.pro.svc.cluster.local",
  "RABBITMQ_PORT": "5671",
  "RABBITMQ_USER": "anjana_mq",
  "RABBITMQ_PASS": "<contrasena-rabbitmq>",
  "RABBITMQ_SSL": "true",

  "VALKEY_HOST": "anjana-pro-valkey.cache.eu-central-1.amazonaws.com",
  "VALKEY_PORT": "6379",
  "VALKEY_PASS": "<contrasena-valkey>",
  "VALKEY_SSL": "true",

  "NEXUS_USER": "<usuario-nexus>",
  "NEXUS_PASS": "<contrasena-nexus>",

  "LICENSE_INSTALLATION_CODE": "<codigo-de-instalacion>",
  "LICENSE_PRIVATE_KEY": "<clave-privada-de-la-instalacion-en-base64>",
  "LICENSE_PUBLIC_KEY": "<clave-publica-de-anjana-data-en-base64>",
  "SCHEDULING_LICENSE": "0 */2 * * * *",

  "INSTALLER_ADMIN_PASSWORD": "<contrasena-inicial-admin>",
  "INSTALLER_DEV_PASSWORD": "<contrasena-inicial-dev>",

  "app.base-url": "https://anjana.miempresa.com/",
  "management.endpoint.env.show-values": "WHEN_AUTHORIZED",
  "management.endpoint.configprops.show-values": "WHEN_AUTHORIZED"
}

5. Secretos por microservicio

Son opcionales y se crean únicamente cuando un microservicio necesita configuración propia que no forma parte del secreto de aplicación. Su contenido sobrescribe la configuración por defecto de ese microservicio y se acumula sobre lo definido en el secreto de aplicación.

5.1 Ejemplo: Zeus

Traslado a propiedades del gestor de secretos de la configuración de aprovisionamiento con Microsoft Azure (Graph API). El equivalente en YAML se documenta en el apartado "Parte 2: Configuración en application.yml" de Microsoft Azure (Graph API).

{
  "security.provisioning.providers.azure-graph.azure-prod.tenant-id": "<tenant-id>",
  "security.provisioning.providers.azure-graph.azure-prod.client-id": "<client-id>",
  "security.provisioning.providers.azure-graph.azure-prod.client-secret": "<client-secret>",
  "security.provisioning.providers.azure-graph.azure-prod.service-principal-id": "<object-id-de-la-aplicacion-empresarial>"
}

La configuración de autenticación mediante SSO se documenta en SSO Azure (apartado "3. Configuración por proveedor"). El contenido de ejemplo completo de este secreto se publica en la documentación de cada mecanismo de autenticación y aprovisionamiento.

5.2 Ejemplo: Hermes

Traslado a propiedades del gestor de secretos de la configuración de proveedores de notificaciones. El equivalente en YAML se documenta en el apartado "1. Configuración en application.yaml" de Proveedores de notificaciones.

{
  "anjana.messaging.google-chat.webhook-url": "https://chat.googleapis.com/v1/spaces/<space>/messages?key=<key>&token=<token>",
  "anjana.messaging.slack.webhook-url": "https://hooks.slack.com/services/<t>/<b>/<token>",
  "anjana.messaging.teams.webhook-url": "https://<tenant>.webhook.office.com/webhookb2/<ruta>",
  "anjana.messaging.connectTimeoutSeconds": "10",
  "anjana.messaging.readTimeoutSeconds": "30",
  "anjana.messaging.writeTimeoutSeconds": "10",
  "spring.mail.host": "smtp.miempresa.com",
  "spring.mail.port": "587",
  "spring.mail.username": "notificaciones@miempresa.com",
  "spring.mail.password": "<contrasena-smtp>",
  "spring.mail.properties.mail.smtp.auth": "true",
  "spring.mail.properties.mail.smtp.starttls.enable": "true"
}

6. Secretos por plugin

Cada Tot Plugin desplegado puede disponer de su propio secreto, con el nombre {prefijo}/{plugin}_default/. Su contenido sobrescribe la configuración por defecto del plugin e incorpora su información específica: parámetros de conexión al sistema origen, ARI asociado, identidad técnica con la que el plugin opera sobre el sistema gobernado y entidades a extraer, entre otros.

A diferencia de los microservicios core, los plugins pueden conectarse directamente al gestor de secretos sin pasar por Horus, ya que pueden desplegarse fuera de la red del core. Los mecanismos de conexión directa a AWS Secrets Manager, GCP Secrets Manager y Azure Key Vault se detallan en Vaults.

7. Permisos de lectura requeridos

La identidad con la que el instalador y la plataforma acceden al gestor de secretos debe poder leer todos los secretos del prefijo del entorno, y únicamente los de ese prefijo. En AWS Secrets Manager, los permisos necesarios son secretsmanager:GetSecretValue y secretsmanager:DescribeSecret sobre {prefijo}/*.

La identidad puede resolverse mediante el perfil de instancia o el rol asociado al despliegue, o bien mediante un rol asumido explícitamente con el parámetro secretsBackend.awsRoleArn del instalador, necesario en escenarios cross-account. Se recomienda evitar claves estáticas siempre que el entorno de despliegue permita asociar una identidad gestionada.

Esta sección está dirigida principalmente a administradores técnicos y a los equipos de arquitectura, seguridad y operaciones responsables de preparar el entorno antes de ejecutar la instalación de Anjana Data Platform.