# Catalyst Blueprint umbrella metadata — the upstream chart is now resolved
# as a Helm subchart via Chart.yaml `dependencies:`. This values.yaml carries
# both:
#   1. The catalystBlueprint metadata block (provenance + version) so
#      observability/audit pipelines can inspect the artifact and report
#      which upstream chart + version is bundled.
#   2. The upstream subchart values overlay under the `keycloak:` key
#      (umbrella-chart convention — the dependency name from Chart.yaml is
#      the values namespace).

global:
  # When set, ALL image pulls in this chart route through this registry.
  # Used post-handover when the Sovereign's own Harbor takes over the
  # proxy_cache role from contabo's central Harbor. Empty = no rewrite
  # (image references use upstream defaults). The upstream Bitnami keycloak
  # chart exposes per-component `keycloak.image.registry`,
  # `keycloak.postgresql.image.registry`, etc. for fine-grained override.
  # Per-Sovereign overlays wire those alongside this value. Tracked under #560.
  imageRegistry: ""

catalystBlueprint:
  upstream: { chart: keycloak, version: "25.2.0", repo: "https://charts.bitnami.com/bitnami" }

# ─── Per-Sovereign identity configuration (issue #604, Phase-8b) ──────────
#
# sovereignFQDN: the Sovereign's base FQDN (e.g. "otech.omani.works").
# Used by the configmap-sovereign-realm.yaml template to render catalyst-ui
# redirect/origin URIs as https://console.<sovereignFQDN>/*.
# REQUIRED when sovereignRealm.enabled — no default per Inviolable Principle #4.
# Per-Sovereign bootstrap-kit HelmRelease overlay supplies this.
sovereignFQDN: ""

# sovereignRealm.enabled: when true, the configmap-sovereign-realm.yaml
# template emits the realm import ConfigMap and keycloakConfigCli references it
# via existingConfigmap. Set false only if running Keycloak without the Sovereign
# realm (e.g. Catalyst-Zero admin-only install — tracked as future work).
#
# sovereignRealm.name: the Keycloak realm name imported by keycloak-config-cli.
# Per `feedback_no_mvp_no_workarounds.md` (target-state = each Sovereign owns
# its KC realm), the canonical realm name is the Sovereign's tenant short-name
# (e.g. `omantel` for omantel.omani.works, `acme` for acme.openova.io). The
# chroot bootstrap-kit overlay supplies it. Default `sovereign` is kept ONLY
# for backward-compat with overlays that haven't been migrated; new Sovereigns
# MUST set this to their tenant short-name. Matrix tests assert paths like
# `/admin/realms/{name}/...` so the value must match the operator's tenant
# convention.
sovereignRealm:
  enabled: true
  name: "sovereign"

# catalystApiServerClientSecret: the client secret for the catalyst-api-server
# confidential client in the sovereign realm.
#
# Resolution order in templates/configmap-sovereign-realm.yaml:
#   1. operator-supplied .Values.catalystApiServerClientSecret (this key)
#   2. helm `lookup` of existing catalyst-kc-sa-credentials Secret
#      in .Release.Namespace (idempotent across upgrades)
#   3. fresh randAlphaNum 32 (zero-touch on first install)
#
# Default empty = self-bootstrap via #3 on a fresh Sovereign. The chart
# materialises both the realm import (with this secret baked into the
# catalyst-api-server client JSON) AND the catalyst-kc-sa-credentials
# Secret in the keycloak namespace, mirrored to catalyst-system by
# emberstack/reflector. catalyst-api consumes the mirror as env vars
# CATALYST_KC_ADDR / CATALYST_KC_REALM / CATALYST_KC_SA_CLIENT_ID /
# CATALYST_KC_SA_CLIENT_SECRET (see products/catalyst/chart/templates/
# api-deployment.yaml).
#
# Set this key only when replicating a known secret from an existing
# sealed-secret / external secret store (rare; the lookup-or-generate
# pattern handles re-provisions automatically). NEVER commit a real
# value here.
catalystApiServerClientSecret: ""

# ─── SMTP for outbound realm email (welcome / password-reset) (issue #604) ─
#
# Pre-handover default: contabo Stalwart relay (cluster-internal FQDN, reachable
# during Phase-8a/8b when the Sovereign is on Hetzner with VPN to contabo).
# Phase-8c-note: migrate to Sovereign-local SMTP relay to eliminate contabo dep.
# password is intentionally empty here — NOT committed in plaintext.
# Per-Sovereign overlay injects it via a SealedSecret-backed HelmRelease valuesFrom.
smtp:
  host: "stalwart-smtp-relay.openova-system.svc.cluster.local"
  port: "587"
  from: "noreply@openova.io"
  user: ""
  password: ""
  ssl: "false"
  starttls: "true"
  auth: "true"

# ─── Per-tenant realm configuration (issue #915, SME multi-tenant SSO) ────
#
# When the bp-keycloak chart is installed for an SME tenant (one Keycloak
# Pod per SME under a per-tenant Namespace), the Sovereign realm import
# is NOT what we want — the tenant has its own realm with per-app OIDC
# clients (wordpress / openclaw / stalwart) so each app federates against
# THIS tenant's identity store, not the Sovereign-wide one.
#
# Set realmConfig.tenant.enabled=true to switch the chart into tenant
# mode:
#   - configmap-sovereign-realm.yaml SKIPS (gated mutual exclusion)
#   - configmap-tenant-realm.yaml RENDERS with the tenant realm JSON
#     and three per-app OIDC client Secrets (wordpress-oidc-client-secret,
#     openclaw-oidc-client-secret, stalwart-oidc-client-secret) that the
#     downstream bp-wordpress-tenant / bp-openclaw / bp-stalwart-tenant
#     charts consume via secretKeyRef.
#   - The keycloak-config-cli post-install Job picks up the tenant
#     ConfigMap (same name `{{ .Release.Name }}-sovereign-realm-config`
#     so the existing existingConfigmap reference still resolves) and
#     imports the tenant realm idempotently.
#
# Per-app client secrets persist via Helm `lookup` (same pattern as
# templates/configmap-sovereign-realm.yaml's catalystApiServerClientSecret
# resolution and products/catalyst/chart/templates/marketplace-api/
# secret.yaml's jwt-secret pattern) — first install generates a fresh
# random; subsequent reconciles re-emit the existing bytes verbatim so
# downstream apps don't see secret rotation.
#
# Per Inviolable Principle #4 (never hardcode), every host-derived field
# is templated off `realmConfig.tenant.parentDomain` +
# `realmConfig.tenant.subdomain` (or operator-supplied per-app hosts).
# Per Inviolable Principle #10 (never print credentials), the per-app
# client secrets only land in the generated K8s Secret bytes — never in
# stdout / logs / git.
realmConfig:
  tenant:
    # Master switch — when false (default), chart stays in Sovereign mode.
    enabled: false
    # Realm name in the tenant Keycloak (e.g. `sme-acme`). REQUIRED when
    # enabled=true. Convention: `sme-<subdomain>` matching the tenant
    # subdomain registered in the SME pool (multi-domain Sovereign #826).
    realmName: ""
    # Display name shown in the Keycloak login UI — typically the SME's
    # company name. Falls back to realmName if blank.
    displayName: ""
    # Tenant admin's email — receives the welcome / password-reset mail
    # when keycloak-config-cli imports the realm with bootstrap users.
    adminEmail: ""
    # Tenant zone fields used to template default redirect / origin URIs.
    # parentDomain example: omantel.omani.works ; subdomain example: acme.
    # The chart computes default per-app hosts as
    # <app>.<subdomain>.<parentDomain> when the per-app `host` is unset.
    parentDomain: ""
    subdomain: ""
    # Default groups bootstrapped in the tenant realm. Mirror the
    # sovereign-admins/sovereign-ops/sovereign-viewers triad at the SME
    # level so RBAC scaffolding is consistent.
    groups:
      - sme-admins
      - sme-users
    # Per-app OIDC client configuration. Each block honours an operator-
    # supplied `clientSecret` (rare; useful for sealed-secret replication)
    # — when blank the chart looks up an existing K8s Secret in the
    # release namespace and persists; on a fresh install a 32-char
    # randAlphaNum value is generated.
    wordpress:
      # Public host the WordPress site is reachable at. Defaults to
      # wordpress.<subdomain>.<parentDomain> when unset.
      host: ""
      # OIDC client ID — the bp-wordpress-tenant chart consumes this
      # via .Values.keycloak.clientID (default "wordpress").
      clientID: "wordpress"
      # Pre-generated client secret. Leave blank for self-bootstrap via
      # lookup-or-generate.
      clientSecret: ""
      # Name of the K8s Secret materialised in the tenant Namespace.
      # bp-wordpress-tenant references this by default
      # (`wordpress-oidc-client-secret`).
      clientSecretName: "wordpress-oidc-client-secret"
      # Redirect URIs registered in Keycloak. Leave empty to use the
      # default templated off the host (the openid-connect-generic
      # WP plugin's admin-ajax.php callback + /wp-login.php).
      redirectURIs: []
    openclaw:
      host: ""
      clientID: "openclaw"
      clientSecret: ""
      clientSecretName: "openclaw-oidc-client-secret"
      # Default redirect URI: https://<host>/oauth/callback (per #915 spec)
      redirectURIs: []
    stalwart:
      host: ""
      clientID: "stalwart"
      clientSecret: ""
      clientSecretName: "stalwart-oidc-client-secret"
      # Stalwart's `directory.keycloak` of type=oidc uses the
      # client_credentials grant (serviceAccountsEnabled=true) to
      # introspect tokens for IMAP/SMTP auth. The webmail UI also uses
      # the auth-code flow — both flows are enabled on the same client
      # by default so a single registration covers both sides.
      redirectURIs: []

# ─── Upstream chart values (subchart key: keycloak) ───────────────────────
# Generated by docs/PROVISIONING-PLAN.md tickets [F] chart Pass 105+.
keycloak:
  auth:
    adminUser: admin
  production: true
  # Chart 25.x renamed `proxy: edge` to `proxyHeaders: "xforwarded"`. Catalyst
  # fronts Keycloak with Cilium Gateway (which sets `X-Forwarded-*`), and we
  # require `proxyHeaders` to be set so chart-level production-mode validation
  # passes without forcing in-pod TLS.
  proxyHeaders: "xforwarded"
  # ─── Bitnami image-registry consolidation (issue #191) ──────────────────
  # Bitnami consolidated their tag scheme around 2025-09 (see
  # https://github.com/bitnami/charts/issues/30852). The original
  # `bitnami/keycloak:<x>-debian-12-rN` tags now 404 in the registry; the
  # preserved historic tags moved to `bitnamilegacy/*` (read-only archive,
  # explicitly published as "no longer updated, may be removed in the
  # future"). Override repository for every Bitnami image referenced by
  # this chart (keycloak app, keycloak-config-cli sidecar, postgresql,
  # postgres-exporter, os-shell init) so `helm install` resolves real
  # manifests. Verified existence with registry HEAD calls before pinning.
  # Tag stays the chart 25.2.0 default (`26.3.3-debian-12-r0`) — re-pin
  # when the chart bumps and we re-verify the new tag.
  image:
    registry: docker.io
    repository: bitnamilegacy/keycloak
    tag: 26.3.3-debian-12-r0
  postgresql:
    enabled: true
    auth:
      username: keycloak
      database: keycloak
    image:
      registry: docker.io
      repository: bitnamilegacy/postgresql
      tag: 17.6.0-debian-12-r0
    metrics:
      image:
        registry: docker.io
        repository: bitnamilegacy/postgres-exporter
        tag: 0.17.1-debian-12-r15
    volumePermissions:
      image:
        registry: docker.io
        repository: bitnamilegacy/os-shell
        tag: 12-debian-12-r50
  ingress:
    enabled: false  # Catalyst uses Cilium Gateway API (see `gateway:` block below), not the upstream chart ingress
  resources:
    requests: { cpu: 250m, memory: 512Mi }
    limits: { memory: 2Gi }
  # ─── Probes — issue #146 (decouple slow Liquibase from livenessProbe) ─────
  #
  # Diagnostic finding (prov #21 + #22): the Keycloak StatefulSet's Service
  # had no Endpoints for 5-10 min after Pod start because Liquibase
  # migrations + JVM cold-start + first realm load take that long before
  # `/realms/master` answers 200. With ONLY a livenessProbe (initialDelay
  # 300s), Liquibase that legitimately runs longer than the probe's grace
  # window is killed mid-flight by the kubelet, restarting the cycle from
  # zero — Pod never reaches Ready.
  #
  # Fix: enable a startupProbe with a 30m budget (failureThreshold 360 ×
  # periodSeconds 5 = 1800s). The kubelet treats startupProbe as an
  # exclusive gate — livenessProbe + readinessProbe are SUSPENDED until
  # startupProbe passes. Once Keycloak first answers /realms/master,
  # liveness+readiness take over with their normal cadence.
  #
  # livenessProbe.initialDelaySeconds dropped 300 → 60 because cold-start
  # protection is now the startupProbe's job; lower initial delay means
  # we detect a genuinely-hung Keycloak ~4 min sooner post-startup.
  #
  # All knobs operator-overridable via per-Sovereign overlay valuesFrom
  # (Inviolable Principle #4: no hardcoding):
  #   keycloak.startupProbe.failureThreshold
  #   keycloak.startupProbe.periodSeconds
  #   keycloak.livenessProbe.initialDelaySeconds
  startupProbe:
    enabled: true
    failureThreshold: 360
    periodSeconds: 5
    timeoutSeconds: 5
    successThreshold: 1
  livenessProbe:
    enabled: true
    initialDelaySeconds: 60
  # ─── keycloak-config-cli: Sovereign realm + kubectl OIDC client (issue #326) ──
  #
  # Bootstrap a `sovereign` realm with a public OIDC client `kubectl` so
  # customer admins on the Sovereign can authenticate `kubectl` against
  # the per-Sovereign K8s api-server (k3s --kube-apiserver-arg=oidc-* in
  # infra/hetzner/cloudinit-control-plane.tftpl). The k3s api-server
  # validates id-tokens issued by `https://auth.<sovereign-fqdn>/realms/
  # sovereign`, so the realm name is invariant per Sovereign — only the
  # issuer hostname differs (Keycloak resolves the issuer claim from the
  # request hostname automatically; no per-Sovereign realm rename needed).
  #
  # Why this is the canonical seam:
  #   The bitnami/keycloak chart ships a post-deploy Job
  #   (templates/keycloak-config-cli-job.yaml) that consumes
  #   `keycloakConfigCli.configuration` as a ConfigMap and runs upstream
  #   `keycloak-config-cli` against the Keycloak Admin API to import the
  #   realm. This is the upstream-supported, idempotent realm-import
  #   mechanism — re-running the Helm install on the same release is a
  #   no-op once the realm exists. Per anti-duplication rule + ADR-0001
  #   §11.3 we MUST NOT replace this with a bespoke kubectl-exec script
  #   or a custom Admin-API call from catalyst-api.
  #
  # `kubectl` client shape:
  #   - publicClient: true (no client secret — kubectl runs locally)
  #   - standardFlowEnabled: true (browser auth-code → localhost:8000)
  #   - directAccessGrantsEnabled: true (allows resource-owner password
  #     grant for non-interactive CI/CD use; customer admins can disable)
  #   - redirectUris: ["http://localhost:8000/*", "urn:ietf:wg:oauth:2.0:oob"]
  #     (kubectl-oidc-login default callback + out-of-band fallback)
  #   - protocolMappers: include `groups` claim in id-token so api-server
  #     can apply group-based RoleBindings (oidc:<group> prefix per
  #     k3s --oidc-groups-prefix flag)
  keycloakConfigCli:
    enabled: true
    # Run the realm-import Job as a Helm post-install/post-upgrade/post-rollback
    # hook (bitnami subchart default — annotations defined on the Job template
    # via .Values.keycloakConfigCli.annotations: helm.sh/hook = post-install,
    # post-upgrade,post-rollback with weight 5). The realm is provisioned
    # exactly once per fresh release; re-run on upgrade is idempotent
    # (config-cli reconciles the realm to spec).
    image:
      registry: docker.io
      repository: bitnamilegacy/keycloak-config-cli
      tag: 6.4.0-debian-12-r11
    # ─── Hook timing — issue #129 (install) + #140 (post-upgrade) ───────────
    #
    # Root cause history (prov #15, otech 0ad3687ddd72deb7, 2026-05-10):
    # Flux's first install of bp-keycloak races against PostgreSQL readiness;
    # when keycloak-config-cli's first run-attempt fires before Keycloak's
    # admin endpoint is reachable, it counts toward Job retries. Bitnami
    # subchart defaults are too tight for a fresh Sovereign:
    #   - availabilityCheck.timeout="" → keycloak-config-cli falls back to
    #     its own internal default (~120s) waiting for Keycloak
    #   - backoffLimit: 1 → only 2 Pod attempts total before Job marked Failed
    # On a brand-new k3s where Postgres+Liquibase migrations + Keycloak
    # bootstrap legitimately take 3-10+ minutes, both attempts time out
    # inside the 120s window → Job Failed → Helm reports
    # "post-upgrade hooks failed: timed out waiting for the condition"
    # → bp-keycloak HelmRelease never reaches Ready=True → bp-gitea
    # (dependsOn keycloak OIDC) never installs → bp-self-sovereign-cutover
    # never converges → fresh provision wedges at phase1-watching.
    #
    # Post-upgrade regression (prov #21, f84f6c3ff2b60296, 2026-05-11):
    # bp-keycloak@1.4.3 HR FAILED with `post-upgrade hooks failed` AFTER
    # Fix #129. Different code path than fresh-install:
    #   - chart-roll on contabo (PR #1346/#1347 stack) triggered an HR
    #     UPGRADE on the new Sovereign. Helm post-upgrade hook fires when
    #     manifests apply (`upgrade.disableWait: true` does NOT skip hooks
    #     — Helm always waits for hook-Pod completion).
    #   - Keycloak StatefulSet pods restart during upgrade (config delta
    #     rolls them); during the rolling restart the Service has 0
    #     Endpoints for tens of seconds.
    #   - Even with availabilityCheck.timeout=600s (10m for inner wait), if
    #     Keycloak's admin endpoint takes > 10m to recover under load
    #     (Liquibase migrations re-validate on restart, JVM warm-up cold
    #     after image-pull on a freshly-provisioned node), the FIRST Pod
    #     attempt times out. With backoffLimit=5 we get up to 6 attempts
    #     total — but each subsequent retry adds an exponential delay
    #     (10s, 20s, 40s, … capped 6m). Worst-case wall-clock for the
    #     hook to complete: 6 × (10m availability + up to 6m backoff) ≈
    #     60m+, which BLOWS PAST the parent HR's 15m upgrade.timeout →
    #     Helm aborts the hook → "post-upgrade hooks failed".
    #
    # Target-state fix (issue #146, post-#140 retune — prov #21 + #22 hung
    # 30+ min on bp-keycloak install). Diagnostic finding: 900s (15m) per
    # availability attempt was TOO COARSE — a single failed attempt busts
    # the 30m HR window before Job-level backoff has any chance to retry.
    # Faster failure beats coarser retry: shrink the per-attempt window so
    # MORE attempts fit inside the HR's 30m envelope.
    #   - availabilityCheck.timeout 900s → 300s (5m). At backoffLimit=5
    #     and 10s..6m exponential backoff this fits ~5 attempts inside
    #     the parent HR's 30m install/upgrade timeout, vs. ~1.5 at 900s.
    #     Each attempt is still long enough to cover one Liquibase pass +
    #     JVM warm-up (typical 90-180s) on a fresh-provisioned node.
    #   - Keep backoffLimit at 5 (Job-level retry handles transient races
    #     without losing state across Helm hook restarts — see HR-side
    #     `install.remediation.retries: 1` in 09-keycloak.yaml).
    #   - cleanupAfterFinished.enabled: true with 1h TTL — without this,
    #     stale Failed/Completed Job pods accumulate across upgrades and
    #     `helm.sh/hook-delete-policy: before-hook-creation` may race with
    #     a still-being-deleted Pod from the previous upgrade, causing
    #     spurious "object is being deleted" hook errors. Bitnami's
    #     ttlSecondsAfterFinished hook surfaces this knob via .seconds.
    #
    # Coupled HR change (clusters/_template/bootstrap-kit/09-keycloak.yaml):
    # install.remediation.retries 3 → 1 + upgrade.remediation.retries 3 → 1.
    # Flux HR remediation retries do a FULL Helm rollback + reinstall on
    # each attempt — losing all hook-Pod state, restarting Liquibase from
    # zero, and consuming a fresh 30m HR timeout per loop. The Job's own
    # backoffLimit=5 already provides retry semantics WITHOUT losing
    # state. HR-level retries on top compound to 90m of wasted work.
    #
    # All knobs remain operator-overridable via per-Sovereign overlay
    # valuesFrom paths (Inviolable Principle #4: no hardcoding):
    #   keycloak.keycloakConfigCli.availabilityCheck.timeout
    #   keycloak.keycloakConfigCli.backoffLimit
    #   keycloak.keycloakConfigCli.cleanupAfterFinished.enabled
    #   keycloak.keycloakConfigCli.cleanupAfterFinished.seconds
    # Operators with faster substrates may shorten them.
    #
    # TODO (issue #146 follow-up — out of scope for this fix per diagnostic
    # "ship knob bumps first to validate hypothesis"): move realm-import
    # OUT of the bitnami post-install Helm hook into a Catalyst-owned
    # Job that runs after Keycloak Service has Endpoints. The Helm-hook
    # design forces the entire HR Ready-state to depend on hook
    # completion; a Catalyst-owned Job decouples HR-Ready from realm-
    # imported and lets the orchestrator wait on the Job CR directly.
    #
    # NOT a workaround per Inviolable Principle #3. The workaround would
    # be disabling the hook semantics entirely (set annotations: {}); that
    # breaks the documented contract that the realm is imported before
    # the Helm release reaches Ready (downstream bp-gitea + catalyst-api
    # depend on the realm existing). Tuning the hook's internal timing
    # AND the outer Helm hook-wait both respect the contract.
    availabilityCheck:
      enabled: true
      timeout: "300s"
    backoffLimit: 5
    # Bitnami exposes ttlSecondsAfterFinished via .cleanupAfterFinished.
    # 3600s = 1h — long enough for an operator post-mortem on a Failed
    # hook Pod, short enough that a re-upgrade an hour later starts clean.
    cleanupAfterFinished:
      enabled: true
      seconds: 3600
    # ─── Phase-8b realm ConfigMap (issue #604, #899) ─────────────────────────
    # The realm import JSON is now owned by the parent bp-keycloak chart's
    # templates/configmap-sovereign-realm.yaml template. That template has
    # access to .Values.sovereignFQDN and .Values.smtp.* for per-Sovereign
    # interpolation — not possible when the JSON lives inside the `keycloak:`
    # subchart values key (subchart scope only sees keycloak.* values).
    #
    # The upstream bitnami/keycloak chart honours `keycloakConfigCli.existingConfigmap`:
    # when set it skips creating its own ConfigMap and uses the named one instead.
    # The bitnami helper "keycloak.keycloakConfigCli.configmapName" applies
    # `tpl` to the value (see charts/keycloak/templates/_helpers.tpl), so we
    # can embed a Helm template expression here that resolves at render time.
    #
    # Name convention: "<releaseName>-sovereign-realm-config" — emitted by
    # templates/configmap-sovereign-realm.yaml at the parent scope. Using
    # `{{ .Release.Name }}` (subchart scope; identical Release object)
    # keeps the reference correct on EVERY install topology:
    #   - Sovereign-mothership bootstrap-kit: releaseName=keycloak →
    #     "keycloak-sovereign-realm-config"
    #   - Per-tenant SME (issue #899): releaseName=bp-keycloak →
    #     "bp-keycloak-sovereign-realm-config"
    # Issue #899 root cause: this was a literal "keycloak-sovereign-realm-config"
    # which broke whenever the operator-supplied releaseName != "keycloak".
    # Per Inviolable Principle #4 (never hardcode): the release-name
    # derivation here is the seam.
    existingConfigmap: '{{ .Release.Name }}-sovereign-realm-config'
  # Metrics + ServiceMonitor + PrometheusRule — DEFAULT OFF.
  #
  # Per docs/INVIOLABLE-PRINCIPLES.md #4 and docs/BLUEPRINT-AUTHORING.md
  # §11.2 (Observability toggles must default false). The upstream
  # bitnami/keycloak chart's `metrics.serviceMonitor.enabled` and
  # `metrics.prometheusRule.enabled` render monitoring.coreos.com/v1
  # resources which the apiserver rejects on a fresh Sovereign before
  # bp-kube-prometheus-stack ships the CRDs. Upstream already defaults
  # all three to false — set explicitly so a future upstream bump cannot
  # regress this. Operator opts in via per-cluster overlay (issue #182).
  metrics:
    enabled: false
    serviceMonitor:
      enabled: false
    prometheusRule:
      enabled: false

# ─── Catalyst HTTPRoute (Cilium Gateway API, issue #387) ──────────────────
# Replaces the upstream chart's networking.k8s.io/v1.Ingress on Sovereigns.
# Per-Sovereign overlay supplies `gateway.host` (e.g. auth.<sovereign-fqdn>).
# parentRef defaults to cilium-gateway/kube-system, the per-Sovereign
# Gateway shipped by clusters/_template/bootstrap-kit/01-cilium.yaml.
gateway:
  enabled: true
  # host: auth.<sovereign-fqdn> — REQUIRED, no default per Inviolable Principle #4
  host: ""
  path: "/"
  # Backend Service — defaults to <release>-keycloak (bitnami subchart fullname)
  backendService: ""
  backendPort: 80
  parentRef:
    name: cilium-gateway
    namespace: kube-system
    # sectionName intentionally empty — multi-zone Sovereigns rename HTTPS
    # listeners to https-<sanitised-zone> (e.g. https-omani-works), so
    # pinning sectionName: https breaks NoMatchingListener. Cilium Gateway
    # matches by hostname filter. See PR #1888 / TBD-A40 / issue #1902.
    sectionName: ""
