TLS Certificate Configuration

When DR is enabled, users access LogScale via the global DR hostname (e.g., <global_hostname>.<dns_zone>) rather than the cluster-specific Azure FQDN. The TLS certificate must include both hostnames as Subject Alternative Names (SANs) for HTTPS to work without certificate warnings.

How it works

The ingress_extra_hostnames variable in main.tf is dynamically constructed when DR is enabled:

terraform
ingress_extra_hostnames = var.dr != "" && var.global_logscale_hostname != "" && var.traffic_manager_dns_zone_name != "" ? [
  "${var.global_logscale_hostname}.${var.traffic_manager_dns_zone_name}"
] : []

This value flows through the logscale-kubernetes module to:

  1. Ingress TLS block: Adds the global hostname to the hosts list

  2. cert-manager ingress-shim: Automatically creates a Certificate with all hosts from the ingress TLS section

Certificate creation flow:

text
main.tf
  |-- ingress_extra_hostnames -->
logscale-kubernetes
  |-- hosts in TLS block -->
Ingress Resource
  |-- cert-manager annotation -->
cert-manager
  |-- creates Certificate -->
TLS Certificate
  |-- includes both SANs -->
K8s TLS Secret

Resulting certificate SANs:

SAN Source
<prefix>.<region>.cloudapp.azure.com logscale_public_fqdn (cluster-specific)
<global_hostname>.<dns_zone> ingress_extra_hostnames (global DR)

Verification:

shell
# Check certificate includes both hostnames
kubectl get certificate <fqdn> -n logging -o jsonpath='{.spec.dnsNames}'
# Expected: ["<cluster-fqdn>","<global_hostname>.<dns_zone>"]
# Verify certificate is valid
kubectl get certificate <fqdn> -n logging -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# Expected: True
# Test HTTPS on global hostname
curl -s -o /dev/null -w "%{http_code}" "https://<global_hostname>.<dns_zone>/api/v1/status"
# Expected: 200

Note

No changes to logscale-kubernetes are required. The existing ingress_extra_hostnames variable and cert-manager's ingress-shim feature handle this automatically.