# 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 `spire:` key
#      (umbrella-chart convention — the dependency name from Chart.yaml is
#      the values namespace; spire is itself a meta-chart with its own
#      sub-subcharts spire-server/spire-agent/etc, which appear as
#      second-level keys nested under `spire:`).

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 spire chart
  # (spiffe hardened) exposes `spire.global.spire.image.registry` for
  # global override. Per-Sovereign overlays wire that alongside this value.
  # Tracked under #560.
  imageRegistry: ""

catalystBlueprint:
  upstream: { chart: spire, version: "0.21.0", repo: "https://spiffe.github.io/helm-charts-hardened" }

# ─── Upstream chart values (subchart key: spire) ──────────────────────────
# Generated by docs/PROVISIONING-PLAN.md tickets [F] chart Pass 105+.
spire:
  global:
    spire:
      clusterName: catalyst
      trustDomain: catalyst.local
      # Recommendations bundle — DEFAULT OFF.
      #
      # Per docs/INVIOLABLE-PRINCIPLES.md #4 and
      # docs/BLUEPRINT-AUTHORING.md §11.2 (Observability toggles must
      # default false). When `recommendations.enabled: true` the upstream
      # spire chart cascades `prometheus: true` into every spire-server /
      # spire-agent telemetry block, which can trigger ServiceMonitor
      # rendering. Upstream already defaults `enabled: false` — we set
      # it explicitly here so a future upstream bump cannot regress this
      # on a fresh Sovereign before bp-kube-prometheus-stack reconciles
      # (issue #182). Operator opts in via per-cluster overlay.
      recommendations:
        enabled: false
        prometheus: false
  spire-server:
    ca_subject:
      country: DE
      organization: OpenOva Catalyst
      common_name: SPIRE CA
    # Disable the default ClusterSPIFFEID resource shipped by the upstream
    # controller-manager. On a fresh Sovereign the CRD is registered by
    # the same chart's pre-install hook, but Helm still tries to apply
    # the controller-manager-cluster-ids.yaml template before the CRD is
    # observable on the API server, producing:
    #   no matches for kind "ClusterSPIFFEID" in version "spire.spiffe.io/v1alpha1"
    # Operators add specific identities post-bootstrap; bootstrap doesn't
    # need a default. Re-enable per-Sovereign when needed.
    controllerManager:
      identities:
        clusterSPIFFEIDs:
          # All 4 default-enabled identities disabled at bootstrap. The
          # CRD is registered by the chart's pre-install hook, but Helm
          # still tries to apply ALL clusterSPIFFEIDs templates before
          # the CRD becomes observable. Operators re-enable per-Sovereign
          # post-bootstrap when SPIRE workloads need identities.
          default:
            enabled: false
          oidc-discovery-provider:
            # Re-DISABLED in bp-spire 1.1.7: the CRD-ordering "fix" in
            # 1.1.6 (spire-crds as Helm dependency) does NOT work because
            # spire-crds ships its CRDs in `templates/` (not `crds/`),
            # and Helm renders subchart templates ALONGSIDE the parent
            # chart's templates rather than installing CRDs first. So
            # the ClusterSPIFFEID CR for oidc-discovery-provider is
            # rejected at install time:
            #   no matches for kind "ClusterSPIFFEID" in version
            #   "spire.spiffe.io/v1alpha1"
            # This blocks bp-spire entirely → cascades to bp-openbao,
            # bp-external-secrets, bp-nats-jetstream (caught live on
            # otech29). The proper architectural fix is splitting bp-spire
            # into bp-spire-crds + bp-spire HRs in the bootstrap-kit so
            # Flux applies CRDs first; until that lands, disabling this
            # CR keeps the chart installable. OIDC provider degraded
            # accordingly — operators that need OIDC can re-enable
            # post-bootstrap once bp-spire-crds split ships.
            enabled: false
          test-keys:
            enabled: false
          # child-servers already defaults false upstream
  spire-agent:
    resources:
      requests: { cpu: 50m, memory: 64Mi }
      limits: { memory: 256Mi }
