Optional configuration — TLS, retention, ClickHouse users, evaluation, and sizing.

All settings on this page are optional — the defaults produce a working deployment. Set them as inputs to the Terraform module.

Data retention (TTL)

ClickHouse retains trace data for a fixed window, after which old data is dropped automatically.

ClickHouse users

The platform provisions a least-privilege ClickHouse user model — one SQL user per access path, each scoped to exactly the operations it performs:

schema_owner, otel, llm_worker, monte_carlo, and probe are always provisioned. readonly_user and admin are opt-in.

Each user's password is generated by the module and stored in Azure Key Vault (RBAC-authorized, purge protection enabled), then synced into the cluster by the External Secrets Operator. Each user has its own secret, exposed as a clickhouse_<user>_credentials_secret_id output. To supply your own passwords instead, set the sensitive clickhouse_passwords input — note the values then also live in your Terraform state. The exception is probe, which is deliberately passwordless — its consumer is the kubelet's readiness check, which can't read a Kubernetes secret — and so has no Key Vault entry; what it can read is limited to replication-health metadata and table names, with no row data exposed.

Read-only user

To provision the optional readonly_user (SELECT-only) for external SQL clients:

helm = {
  chart_registry = "oci://registry-1.docker.io/montecarlodata"
  chart_version  = "4.0.0"

  clickhouse = {
    readonly_user = {
      enabled = true
    }
  }
}

Its password's Key Vault secret ID is exposed as the clickhouse_readonly_user_credentials_secret_id output. Remember that external clients reach ClickHouse through the Gateway over HTTPS on port 8443 — configure JDBC/HTTP clients accordingly (the native TCP protocol is not exposed).

Break-glass admin user

The admin superuser is opt-in and, by default, reachable only over loopback (pod-exec) — it is never on a network path. Enable it for break-glass DBA access:

helm = {
  chart_registry = "oci://registry-1.docker.io/montecarlodata"
  chart_version  = "4.0.0"

  clickhouse = {
    admin = {
      enabled = true
    }
  }
}

Its password's Key Vault secret ID is exposed as the clickhouse_admin_credentials_secret_id output (null when disabled).

Resource sizing

Each managed workload exposes optional Kubernetes resource requests/limits via helm.<workload>.resources. Omit a workload (or a requests/limits map) to use the chart defaults — start modest in development and tune up for production.

helm = {
  chart_registry = "oci://registry-1.docker.io/montecarlodata"
  chart_version  = "4.0.0"

  clickhouse = {
    resources = {
      requests = { cpu = "2", memory = "8Gi" }
      limits   = { cpu = "4", memory = "16Gi" }
    }
  }
  opentelemetry_collector = {
    resources = {
      requests = { memory = "2Gi" }
      limits   = { memory = "6Gi" }
    }
  }
  llm_worker = {
    resources = {
      requests = { cpu = "500m", memory = "1Gi" }
      limits   = { cpu = "2", memory = "4Gi" }
    }
  }
}

requests and limits are maps keyed by Kubernetes resource name (cpu, memory, ephemeral-storage, etc.); either can be omitted independently.

There are no replica-count overrides for the Collector or the LLM worker on Azure — both run at the chart's defaults. ClickHouse replicas are controlled by clickhouse_replica_count (see High availability below).

Node pools (new-cluster path)

On the new-cluster path, you can size the node pools the workloads run on:

Node images are pinned by default (node-OS upgrade channel None); roll the stateless pool deliberately by setting or changing node_image_upgrade_token, and upgrade the stateful pools on your own schedule — see High availability — node-image updates. The cluster's Kubernetes version is pinned via kubernetes_version (default "1.35").

High availability

The topology inputs below deploy the standard HA shape — how it works, the dev/testing single-replica variant, and day-2 operations are covered on the High availability page.

Storage

ClickHouse data is stored on an Azure managed-disk persistent volume.

Network access

The platform's endpoints sit on a single managed Gateway backed by an internal load balancer — nothing is exposed to the public internet. The controls below govern who can reach what:

Two further network facts worth knowing:

• Egress is a NAT gateway. Module-created VNets route outbound traffic through a NAT gateway with a static public IP, so pulls from Docker Hub, Let's Encrypt validation, and Foundry calls present one stable source address.
• etcd is encrypted with your key. New clusters enable AKS KMS etcd encryption with a customer-managed key in the module's Key Vault.

TLS

TLS is enabled by default and terminates on the managed Gateway. cert-manager issues publicly-trusted Let's Encrypt certificates for your otel_collector_domain and clickhouse_domain via DNS-01 validation against dns_zone, and renews them automatically — there are no certificate resources to manage or rotate yourself. Behind the Gateway, traffic is re-encrypted to the Collector's and ClickHouse's in-cluster certificates (issued by cert-manager, validated via trust-manager), so it is encrypted end to end.

The Gateway is HTTP-family (L7) only: telemetry is ingested as OTLP over HTTP (not gRPC), and ClickHouse is served over its HTTPS interface on port 8443 — the native TCP protocol is not exposed. "Publicly trusted" describes the certificate chain; the endpoints stay on a private IP.

Evaluation (Microsoft Foundry)

The LLM worker performs evaluation by calling Claude on a Microsoft Foundry resource the module provisions — an AIServices account, a project, and one deployment per curated Claude model, with a custom least-privilege inference role granted to the worker's Workload Identity. Authentication is Entra-only (disableLocalAuth = true — no API keys anywhere), over the account's public endpoint.

Claude model availability and tokens-per-minute quota vary by region and subscription — verify both for the Foundry region (helm.llm_worker.foundry.location, defaulting to your location) in the Azure portal before relying on the defaults, and check current model IDs there if a deployment fails to create.

The account name, account ID, project name, and project ID are exposed as the foundry_account_name, foundry_account_id, foundry_project_name, and foundry_project_id outputs.

Ingestion into the platform is OTLP push only — there is no object-storage (blob) ingest path on Azure, and the Collector runs with no cloud identity at all.