Advanced k8s

This Annex covers all the information about possible configurations and utilities not covered on the kit's main page for 26.k1.

anjana-secrets explained

The kit includes the file anjana.env.example, which documents all the keys expected by the anjana-secrets Secret. The available configuration groups are detailed below:

Persistence connection strings

All persistence connection keys follow the pattern persistences.<service>.<property>:

• persistences.bbdd.user and persistences.bbdd.pass: PostgreSQL access credentials. They are used both to initialize the in-cluster PostgreSQL StatefulSet and for Horus to serve the connection URL to the rest of the services.

• persistences.bbdd.url: connection URL in host:port/db format. Example: postgresql:5432/anjana. In cloud deployments it points to RDS.

• persistences.mongodb.user and persistences.mongodb.pass: MongoDB credentials.

• persistences.rabbitmq.user and persistences.rabbitmq.pass: RabbitMQ credentials.

• persistences.valkey.pass: Valkey password (Redis compatible).

• persistences.s3.access_key and persistences.s3.secret_key: S3 access credentials (AWS S3 or SeaweedFS). They are used to initialize SeaweedFS and to configure the CDN proxy.

• anjana.domain: access domain for the Anjana instance. ✅RECOMMENDED: leave the value managed by anjana setup to ensure consistency with the TLS certificates.

License configuration

The license is required for the platform to operate and must be included in the credentials bundle. Contact the Anjana Data team to obtain the license values corresponding to your environment.

Horus and cloud services configuration

In cloud mode (AWS), service configuration credentials are read directly from AWS Secrets Manager via IRSA. In that case, only the local persistence keys are needed in anjana-secrets.

Instance provisioning

values-example.yaml as reference

The kit includes values-example.yaml with all the chart options commented. ✅RECOMMENDED: use it as a reference to build the values-<env>.yaml file for each environment, overriding only what is necessary.

Environment profiles (DEV / PRE / PRO)

The active profile is controlled with global.environment.profile and determines the CPU/memory requests and limits of each microservice:

• DEV: lab or local environments, minimal resources.

• PRE (default): pre-production / UAT.

• PRO: production, expanded resources.

global:
  environment:
    profile: PRO

The values per service and profile are defined in charts/anjana-core/values.yaml (resourcesProfile field). To adjust a specific service, define its resources block in the values override: it takes priority over the profile. The table of total capacity per profile is in the Deployment Manual, in the "Cluster resource requirements" section.

Validation guardrails

The chart validates prerequisites at render time (global.guardrails.mode):

• strict (default): installation fails if any prerequisite is missing. Among other things, it validates: the ClusterIssuer and the password/truststore/CA Secrets for internal TLS mode, and that exactly one Config Server backend is enabled.

• permissive: only warns. Useful for validating locally (make test) or in a lab environment.

global:
  guardrails:
    mode: permissive

TLS mode: internal vs manual

The TLS mode is controlled with global.tls.mode in the values file:

Mode internal (recommended): cert-manager automatically generates and renews certificates using a ClusterIssuer. No manual certificate management is required.

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

Mode manual: uses pre-existing certificates. The paths must be exported before running 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

Managing kubectl aliases

For quick access to the Anjana namespace, you can configure an alias in your shell:

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

Cloud integrations

Buckets in AWS S3

To use buckets in AWS S3 instead of SeaweedFS, configure the CDN mode in the values file:

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

And disable the in-cluster S3 persistence layer:

anjana-persistences:
  seaweedfs:
    enabled: false

The S3 access credentials (persistences.s3.access_key and persistences.s3.secret_key) must be in the anjana-secrets bundle. In AWS environments with IRSA, the credentials are automatically managed by the IAM Role assigned to the Horus ServiceAccount.

PostgreSQL on RDS

To use RDS instead of the in-cluster PostgreSQL StatefulSet:

1. Disable in-cluster PostgreSQL in the values file:

anjana-persistences:
  postgresql:
    enabled: false

2. Update the connection URL in the credentials bundle:

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

The nature of the connection string is directly compatible with RDS with no additional changes.

DNS resolution for the CDN proxy (nginxResolver)

The nginx in anjana-ui resolves the CDN upstream at startup using the system resolver. If your Kubernetes distribution needs an explicit resolver, set the kube-dns ClusterIP in the values:

global:
  nginxResolver: "10.96.0.10"

With the empty value (default), the image's resolver is used.

Plugin activation (connectors)

The anjana-plugins subchart includes 20 connectors, all disabled by default:

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

Activating a connector requires three adjustments:

1. Enable the subchart in the values file:

anjana-plugins:
  enabled: true

2. Set the connector version in global.version.plugins (check with the Anjana Data team for the version corresponding to your release):

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

3. Set enabled: true on the connector entry within the plugins list of charts/anjana-plugins/values.yaml.

NOTE: tp-databricks has a port and secret fields reserved in the installer, but anjana-ansible does not yet have the connector's role built; it remains in the chart as a definition ready to be activated once the connector is available.

Standalone plugin configuration

By default, plugins get their configuration through Horus. With global.plugins_config.standalone: true, they can read it from their own backend, with two mutually exclusive options under global.plugins_config.secrets_backend:

• aws_secrets_manager: AWS credentials in a Kubernetes Secret (plugins-aws-creds with the accessKeyId / secretAccessKey keys) and a configurable region.

• aes_file: AES-encrypted configuration file mounted from a Secret (plugins-aes-config), with the passphrase in another 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

Version management

Versions are controlled individually in the chart's values, without modifying manifest YAML files:

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

To update a single service, change its version and run helm upgrade.

Security management in Anjana

Certificate management and renewal

In internal mode, cert-manager automatically manages renewal before the certificate expires. No manual intervention is required.

In manual mode, it is the operator's responsibility to renew the certificate before it expires by running anjana setup with the new exported certificate files.

CORS restriction and gateway protections

When global.domain is set, the API gateway (viator) restricts CORS exclusively to that origin. With the empty value (default), any origin is allowed, which is a less secure option.

global:
  domain: "anjana.cliente.com"

In addition, the front-ends and the gateway include out of the box (with no additional configuration): rate limiting on the login endpoint, HTTP security headers, and propagation of the X-traceId trace identifier to correlate requests in the logs when working with support.

Front-end security

In this kit, the front-ends (anjana-ui, portuno-ui) are Deployments with nginx. To secure them:

Both front-ends share the same port 443 and are distinguished by path (/ for anjana-ui, /configpanel for portuno-ui), not by port - if you expose the kit behind your own on-prem Ingress, the separation is done with two path rules on the same port on each Service.

Customizing the front-ends' nginx configuration

The front-ends (anjana-ui, portuno-ui) come with their nginx configuration (reverse proxy to internal services, SPA routes, security headers) included in the image. By default there is no need to touch anything: the image works with no additional configuration.

If you need to customize it (extra headers, IP restriction, additional routes...), the chart allows you to override it with your own ConfigMap, without modifying the image or manually accessing the pod:

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

The ConfigMap must be created before helm install/upgrade, with a single default.conf.template key containing the complete nginx configuration (it is not a partial patch: it replaces the front-end's entire server block). Use config-reference/config-core/anjana-ui.config.yaml or portuno-ui.config.yaml from the kit as a starting point - they are the actual template shipped in the image, extracted directly from it.

Utilities

SeaweedFS - Bucket management

If you use SeaweedFS as local S3 storage, the buckets must be created manually after the first deployment:

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'

Governance dashboards (Grafana)

The kit includes, in anjana-dashboards/, a Grafana deployment with preconfigured datasources and provisioning, along with the Anjana data governance dashboard (anjana-data-governance.yaml):

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

Configuration reference (config-reference/)

The config-reference/ directory documents the configuration keys expected by each service. These are reference files: they are not applied during installation; the authoritative configuration source is the encrypted bundle (secrets/anjana.env.aes) or AWS Secrets Manager depending on the mode.

Exception: anjana-ui.config.yaml and portuno-ui.config.yaml are indeed meant to be applied - they are the base to start from for nginxConfigOverride (see the "Customizing the front-ends' nginx configuration" section above).

To inspect the effective configuration a service receives:

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

# Query the configuration table in PostgreSQL
kubectl -n anjana-data exec -it postgresql-0 -- \
  psql -U anjana -d anjana -c "SELECT key, value FROM app_configuration LIMIT 50;"