Avanzado k8s

Este Anexo abarcará toda la información sobre las posibles configuraciones y utilidades no cubiertas en la página principal del kit 26.k1.

anjana-secrets explicado

En el kit se incluye el fichero anjana.env.example, en el cual se documentan todas las claves esperadas por el Secret anjana-secrets. A continuación se detallan los grupos de configuración disponibles:

Cadenas de conexión de persistencias

Todas las claves de conexión a persistencias siguen el patrón persistences.<servicio>.<propiedad>:

• persistences.bbdd.user y persistences.bbdd.pass: credenciales de acceso a PostgreSQL. Se usan tanto para inicializar el StatefulSet de PostgreSQL en cluster como para que Horus sirva la URL de conexión al resto de servicios.

• persistences.bbdd.url: URL de conexión en formato host:port/db. Ejemplo: postgresql:5432/anjana. En despliegues cloud apunta a RDS.

• persistences.mongodb.user y persistences.mongodb.pass: credenciales de MongoDB.

• persistences.rabbitmq.user y persistences.rabbitmq.pass: credenciales de RabbitMQ.

• persistences.valkey.pass: contraseña de Valkey (Redis compatible).

• persistences.s3.access_key y persistences.s3.secret_key: credenciales de acceso a S3 (AWS S3 o SeaweedFS). Se usan para inicializar SeaweedFS y para la configuración del CDN proxy.

• anjana.domain: dominio de acceso a la instancia de Anjana. ✅RECOMENDADO: dejar el valor gestionado por anjana setup para garantizar la coherencia con los certificados TLS.

Configuración de licencia

La licencia es requerida para el funcionamiento de la plataforma y debe incluirse en el bundle de credenciales. Consulta con el equipo de Anjana Data para obtener los valores de licencia correspondientes a tu entorno.

Configuración de Horus y servicios cloud

En modo cloud (AWS), las credenciales de configuración de servicios se leen directamente de AWS Secrets Manager mediante IRSA. En ese caso, solo las claves de persistencias locales son necesarias en anjana-secrets.

Plataformado de instancias

values-example.yaml como referencia

El kit incluye values-example.yaml con todas las opciones del chart comentadas. ✅RECOMENDADO: usarlo como referencia para construir el fichero values-<env>.yaml de cada entorno, sobreescribiendo solo lo necesario.

Perfiles de entorno (DEV / PRE / PRO)

El perfil activo se controla con global.environment.profile y determina los requests y limits de CPU/memoria de cada microservicio:

• DEV: entornos de laboratorio o locales, recursos mínimos.

• PRE (por defecto): preproducción / UAT.

• PRO: producción, recursos ampliados.

global:
  environment:
    profile: PRO

Los valores por servicio y perfil están definidos en charts/anjana-core/values.yaml (campo resourcesProfile). Para ajustar un servicio concreto, define su bloque resources en el values override: tiene prioridad sobre el perfil. La tabla de capacidad total por perfil está en el Manual de despliegue, sección "Requisitos de recursos del cluster".

Guardrails de validación

El chart valida prerrequisitos en tiempo de renderizado (global.guardrails.mode):

• strict (por defecto): la instalación falla si falta algún prerrequisito. Valida, entre otros: el ClusterIssuer y los Secrets de contraseñas/truststore/CA del modo TLS internal, y que hay exactamente un backend de Config Server habilitado.

• permissive: solo avisa. Útil para validar en local (make test) o en laboratorio.

global:
  guardrails:
    mode: permissive

Modo TLS: internal vs manual

El modo TLS se controla con global.tls.mode en el fichero de values:

Modo internal (recomendado): cert-manager genera y renueva automáticamente los certificados usando un ClusterIssuer. No requiere gestión manual de certificados.

global:
  tls:
    mode: internal
    internal:
      clusterIssuerName: "anjana-internal-ca"

Modo manual: usa certificados pre-existentes. Es necesario exportar las rutas antes de ejecutar anjana setup:

export ANJANA_KEYSTORE_P12=/path/to/anjana-ssl.keystore.p12
export ANJANA_CACERTS=/path/to/cacerts
export ANJANA_FULLCHAIN_PEM=/path/to/fullchain.pem
export ANJANA_PRIVKEY_PEM=/path/to/privkey.pem

anjana setup anjana-data

Gestión de aliases kubectl

Para un acceso rápido al namespace de Anjana, puedes configurar un alias en tu shell:

alias k='kubectl -n anjana-data'
alias kgp='kubectl get pods -n anjana-data'
alias klogs='kubectl logs -n anjana-data'

Integraciones cloud

Buckets en AWS S3

Para usar buckets en AWS S3 en lugar de SeaweedFS, configura el modo CDN en el fichero de values:

global:
  cdnProxy:
    mode: aws_s3
    bucket: "anjana-prod-cdn"
    aws_s3:
      region: "eu-central-1"

Y deshabilita las persistencias S3 en cluster:

anjana-persistences:
  seaweedfs:
    enabled: false

Las credenciales de acceso a S3 (persistences.s3.access_key y persistences.s3.secret_key) deben estar en el bundle anjana-secrets. En entornos AWS con IRSA, las credenciales las gestiona automáticamente el IAM Role asignado al ServiceAccount de Horus.

PostgreSQL en RDS

Para usar RDS en lugar del StatefulSet de PostgreSQL en cluster:

1. Deshabilita PostgreSQL en cluster en el fichero de values:

anjana-persistences:
  postgresql:
    enabled: false

2. Actualiza la URL de conexión en el bundle de credenciales:

# En horus.env
persistences.bbdd.url=my-rds-instance.eu-central-1.rds.amazonaws.com:5432/anjana
persistences.bbdd.user=anjana
persistences.bbdd.pass=<contraseña>

La naturaleza de la cadena de conexión es compatible directamente con RDS sin cambios adicionales.

Resolución DNS del proxy CDN (nginxResolver)

El nginx de anjana-ui resuelve el upstream del CDN en el arranque con el resolver del sistema. Si tu distribución Kubernetes necesita un resolver explícito, fija la ClusterIP de kube-dns en el values:

global:
  nginxResolver: "10.96.0.10"

Con el valor vacío (por defecto) se usa el resolver de la imagen.

Activación de plugins (conectores)

El subchart anjana-plugins incluye 20 conectores, todos desactivados por defecto:

tp-aqtiva tp-aws-glue tp-aws-iam tp-aws-s3 tp-az-ad tp-az-storage tp-gcp-bigquery tp-gcp-iam tp-gcp-storage tp-jdbc tp-jdbc-denodo tp-jdbc-oracle tp-jdbc-redshift tp-jdbc-snowflake tp-jdbc-sqlserver tp-ldap tp-powerbi tp-ranger tp-tableau tp-databricks

Para activar un conector hacen falta tres ajustes:

1. Habilitar el subchart en el fichero de values:

anjana-plugins:
  enabled: true

2. Fijar la versión del conector en global.version.plugins (consulta con el equipo de Anjana Data la versión correspondiente a tu release):

global:
  version:
    plugins:
      tp-jdbc: "5.2.0"

3. Marcar enabled: true en la entrada del conector dentro de la lista plugins de charts/anjana-plugins/values.yaml.

NOTA: tp-databricks tiene puerto y campos de secreto reservados en el installer, pero anjana-ansible aún no tiene construido el role del conector; queda en el chart como definición lista para activarse cuando el conector esté disponible.

Configuración de plugins standalone

Por defecto los plugins obtienen su configuración a través de Horus. Con global.plugins_config.standalone: true pueden leerla de un backend propio, con dos opciones excluyentes bajo global.plugins_config.secrets_backend:

• aws_secrets_manager: credenciales AWS en un Secret de Kubernetes (plugins-aws-creds con las claves accessKeyId / secretAccessKey) y región configurable.

• aes_file: fichero de configuración cifrado AES montado desde un Secret (plugins-aes-config), con la passphrase en otro Secret.

global:
  plugins_config:
    standalone: true
    secrets_backend:
      aes_file:
        enabled: true
        secretName: plugins-aes-config
        encryptedFileKey: application.yaml.aes
        passphraseSecret:
          name: plugins-aes-config
          key: passphrase

Gestión de versiones

Las versiones se controlan de forma individual en los values del chart, sin modificación de YAMLs de manifiestos:

global:
  version:
    core:
      horus: 6.0.0
      hermes: 6.0.0
      kerno: 6.0.0
      minerva: 6.0.0
      portuno: 6.0.0
      tot: 5.2.0
      viator: 6.0.0
      zeus: 6.1.0
      drittesta: 6.0.0
      marketplace: 1.0.0
      anjana-ui: 5.2.0
      portuno-ui: 5.2.0
      adp-mcp: 1.0.0

Para actualizar un único servicio, modifica su versión y ejecuta helm upgrade.

Gestión de la seguridad en Anjana

Gestión y renovación de certificado

En modo internal, cert-manager gestiona la renovación automáticamente antes de que el certificado expire. No se requiere intervención manual.

En modo manual, es responsabilidad del operador renovar el certificado antes de su expiración ejecutando anjana setup con los nuevos ficheros de certificado exportados.

Restricción de CORS y protecciones del gateway

Cuando se define global.domain, el API gateway (viator) restringe CORS exclusivamente a ese origen. Con el valor vacío (por defecto) se permite cualquier origen, opción menos segura.

global:
  domain: "anjana.cliente.com"

Además, los frontales y el gateway incorporan de serie (sin configuración adicional): limitación de tasa de peticiones en el endpoint de login, cabeceras de seguridad HTTP y propagación del identificador de traza X-traceId para correlar peticiones en los logs al trabajar con soporte.

Seguridad en los frontales

En este kit los frontales (anjana-ui, portuno-ui) son Deployments con nginx. Para securizarlos:

Ambos frontales comparten el mismo puerto 443 y se distinguen por path (/ para anjana-ui, /configpanel para portuno-ui), no por puerto — si expones el kit detrás de tu propio Ingress on-prem, la separación se hace con dos reglas de path sobre el mismo puerto en cada Service.

Personalizar la configuración nginx de los frontales

Los frontales (anjana-ui, portuno-ui) traen su configuración nginx (reverse proxy a los servicios internos, rutas de la SPA, cabeceras de seguridad) incluida en la imagen. Por defecto no hace falta tocar nada: la imagen funciona sin configuración adicional.

Si necesitas personalizarla (cabeceras extra, restricción por IP, rutas adicionales...), el chart permite sobrescribirla con tu propia ConfigMap, sin modificar la imagen ni entrar al pod manualmente:

core:
  - name: portuno-ui
    nginxConfigOverride:
      enabled: true
      configMapName: "portuno-ui-nginx-override"

La ConfigMap debe crearse antes del helm install/upgrade, con una única clave default.conf.template que contenga la configuración nginx completa (no es un parche parcial: sustituye todo el server block del frontal). Usa config-reference/config-core/anjana-ui.config.yaml o portuno-ui.config.yaml del kit como punto de partida — son la plantilla real que trae la imagen, extraída directamente de ella.

Utilidades

SeaweedFS - Gestión de buckets

Si usas SeaweedFS como almacenamiento S3 local, los buckets deben crearse manualmente tras el primer despliegue:

kubectl exec seaweedfs-0 -n anjana-data -c seaweedfs -- sh -c \
  'printf "s3.bucket.create -name cdn
s3.bucket.create -name dsa
s3.bucket.create -name imports
s3.bucket.create -name textarea
s3.bucket.create -name workflows
s3.bucket.create -name datadump
s3.bucket.create -name anjanalogs
" \
  | weed shell -master=localhost:9333 -filer=localhost:8888 2>/dev/null'

Dashboards de gobierno (Grafana)

El kit incluye en anjana-dashboards/ un despliegue de Grafana con datasources y aprovisionamiento preconfigurados, junto con el dashboard de gobierno del dato de Anjana (anjana-data-governance.yaml):

kubectl apply -f anjana-dashboards/ -n <namespace>

Referencia de configuración (config-reference/)

El directorio config-reference/ documenta las claves de configuración que espera cada servicio. Son ficheros de referencia: no se aplican durante la instalación; la fuente autoritativa de configuración es el bundle cifrado (secrets/anjana.env.aes) o AWS Secrets Manager según el modo.

Excepción: anjana-ui.config.yaml y portuno-ui.config.yaml sí están pensados para aplicarse — son la base de la que partir para nginxConfigOverride (ver sección "Personalizar la configuración nginx de los frontales" más arriba).

Para inspeccionar la configuración efectiva que recibe un servicio:

# Consultar Horus Config Server directamente
kubectl -n anjana-data exec -it horus-0 -- curl -sk https://horus:9999/portuno/default | jq

# Consultar la tabla de configuración en PostgreSQL
kubectl -n anjana-data exec -it postgresql-0 -- \
  psql -U anjana -d anjana -c "SELECT key, value FROM app_configuration LIMIT 50;"