Skip to main content

Cloud Architecture on Azure

High-level cloud architecture for deploying the BigHammer platform on Azure Kubernetes Service (AKS) using the platform umbrella Helm chart.

This document describes components and data flows in a cloud-agnostic, environment-neutral way. Replace placeholders such as <your-keyvault>, <your-domain>, and <your-namespace> with values from your deployment.


Architecture overview


Deployment layers

LayerResponsibility
Azure foundationAKS, Key Vault, PostgreSQL, storage, ACR, DNS, optional private endpoints / VNet integration
Cluster add-onsExternal Secrets Operator, NGINX Ingress Controller, Stakater Reloader, optional Redis
MessagingRabbitMQ (separate Helm release; referenced by APIs and workers)
Platform chartUmbrella chart — APIs, UI, workers, Keycloak, ingress rules, SecretStore
Orchestration (optional)airflow-azure — workflow scheduling in a dedicated namespace

Platform umbrella chart

The platform umbrella chart packages the application stack as sub-charts, each toggled with global.<subchart>.enabled.

Sub-charts

Sub-chartTypePurpose
bhuiDeployment + IngressMain web UI
bhadminuiDeploymentAdministration UI
bhcatalogapiDeploymentCatalog / metadata API
bhauditapiDeploymentAudit API
bhaiagentDeploymentAI agent API
bhkeycloakDeploymentIdentity broker (SSO)
bhkeycloakapiDeploymentKeycloak administration API
bhnginxDeploymentReverse proxy in front of Keycloak
bhtransformationutilsDeploymentTransformation utilities API
bhcatalogworkerDeploymentCelery worker for catalog jobs
bhauditworkerDeploymentCelery worker for audit jobs
bhaiagentworkerDeploymentCelery worker for AI agent jobs
bhcelerybeatDeploymentCelery beat scheduler

Parent-chart resources

In addition to sub-charts, the umbrella chart creates:

ResourcePurpose
SecretStoreNamespace-scoped Azure Key Vault provider for External Secrets
external-secrets-operator ServiceAccountWorkload Identity–enabled SA used by ESO to read Key Vault
Storage ExternalSecretSyncs blob account name/key for schema mounts
Shared blob PV/PVCOptional ReadWriteMany volume for shared schema files (global.azureBlobSchemas)

RabbitMQ and Redis are not sub-charts of the platform umbrella chart. Deploy them as separate releases in the same or a peer namespace and point services at bhrabbitmq.<namespace>.svc.cluster.local and bhredis-master.<namespace>.svc.cluster.local in your values file.


Request and authentication flow

Airflow (when deployed) typically uses direct Entra OAuth rather than the Keycloak broker. See Airflow Azure Deployment.


Ingress routing

A single Ingress resource (defined in the bhui sub-chart) terminates TLS and routes by hostname. Hostnames are configured under global.ingress in your values file.

Ingress host keyTypical backend servicePort
uiHostNamebhui80
adminuiHostNamebhadminui80
catalogHostNamebhcatalogapi80
auditHostNamebhauditapi80
aiAgentHostNamebhaiagent80
kcHostNamebhkeycloak80
kcapiHostNamebhkeycloakapi80
transformationUtilsHostNamebhtransformationutils80
rabbitmqHostNamebhrabbitmq (management UI)15672

TLS uses a Kubernetes secret name from global.ingress.tlsSecretName, populated by an ExternalSecret that reads the wildcard certificate from Key Vault.


Secrets architecture

  • Each enabled sub-chart creates an ExternalSecret referencing the namespace SecretStore.
  • The chart deploys a dedicated external-secrets-operator ServiceAccount in the platform namespace with azure.workload.identity annotations (global.secretStore.managedIdentityClientId).
  • Sensitive values (database passwords, API keys, TLS material) are never stored in Git; only non-secret configuration lives in values files.
  • Stakater Reloader (global.annotations.reloader.stakater.com/auto) restarts pods when synced secrets change.

For the full secret name list, see Key Vault Secrets.


Data stores

PostgreSQL

Azure Database for PostgreSQL Flexible Server hosts:

  • A main application database (e.g. bighammer_db_<env>) with schemas: catalog_db, agent_db, audit_db, celery_db, keycloakapi_db, llm_observability_db
  • Keycloak database (e.g. keycloak_db_<env>)
  • Optional SonarQube database

Database bootstrap is automated by install scripts (see Scripts Reference).

Azure Blob Storage

Used for:

  • Pipeline / catalog schemas (global.azureBlobSchemas)
  • Application utilities and static assets (per-service azureBlob settings)
  • Optional shared ReadWriteMany mount via Blob CSI

Redis (optional)

The AI agent stack uses Redis for caching/session state when a Redis release is deployed and referenced in global.bhaiagent.env.

RabbitMQ

Celery workers and APIs publish/consume tasks via RabbitMQ. Password is synced from Key Vault (bh-rabbitmq-password).


Async processing

See RabbitMQ & Celery Workers for worker configuration patterns.


Workload Identity

Pods authenticate to Azure without embedded credentials:

  1. AKS — OIDC issuer and Workload Identity enabled
  2. User-assigned managed identity — granted Key Vault Secrets User, AcrPull, and storage roles as needed
  3. Federated credentials — link Kubernetes service accounts to the managed identity
  4. Pod / SA annotationsazure.workload.identity/client-id and azure.workload.identity/use: "true"

Details: Workload Identity.


Optional: Airflow

Deploy airflow-azure in a separate namespace. It reuses:

  • The same Key Vault (often via ClusterSecretStore)
  • Wildcard TLS secrets
  • PostgreSQL (airflow database) and/or Blob for DAG storage

See Airflow Azure Deployment and ClusterSecretStore for TLS.


Network and ports (reference)

TrafficProtocolPortNotes
User → IngressHTTPS443Public or private ingress depending on deployment
Ingress → servicesHTTP80TLS terminated at ingress
APIs → PostgreSQLTCP5432Use sslmode=require
Workers → RabbitMQAMQP5672In-cluster service DNS
RabbitMQ management (ingress)HTTPS443Proxied to 15672
Key Vault / Blob / ACRHTTPS443Via private endpoint or Azure backbone