# ServiceAccount used by the catalyst-api Pod to drive the
# self-sovereignty cutover endpoint (issue #792).
#
# After handover, catalyst-api on the Sovereign cluster handles
# POST /api/v1/sovereign/cutover/start. The handler:
#   - reads the cutover-step PodSpec ConfigMaps in the `catalyst` namespace
#     (selected by app.kubernetes.io/part-of=self-sovereign-cutover)
#   - stamps batchv1.Job objects from those PodSpecs in the same namespace
#   - patches the self-sovereign-cutover-status ConfigMap as each step
#     transitions, recording state machine progress
#   - watches Job status to completion / Failed
#   - inspects DaemonSet readiness for daemonset-wait steps
#
# catalyst-api itself runs in:
#   - `catalyst` namespace on contabo-mkt (deployed via Kustomize from
#     ./products/catalyst/chart/templates with namespace: catalyst).
#   - `catalyst-system` namespace on Sovereigns (deployed via Helm with
#     targetNamespace: catalyst-system from the bp-catalyst-platform OCI
#     chart).
# Both deployment paths fill in metadata.namespace automatically (Helm
# from --namespace, Kustomize from its namespace: directive). The same
# auto-fill propagates into ClusterRoleBinding subjects[0].namespace —
# verified with kubectl kustomize on a fixture binding (PR #831 follow-up
# after Kustomize-mode contabo deploy dropped this resource because the
# original {{ .Release.Namespace }} directive made Kustomize parse the
# file as invalid YAML and silently skip it).
#
# NOTE — DUAL-MODE CONTRACT (api-deployment.yaml has the canonical
# explanation): every file in this directory is consumed BOTH by Helm
# (per-Sovereign install) AND by Kustomize (contabo via flux Kustomization
# at path: ./products/catalyst/chart/templates). Helm template syntax
# (double-curly directives) here breaks the Kustomize build. Hence NO
# Helm directives in this file at all — namespace auto-fills, no other
# Helm context is needed.
#
# Why a dedicated SA (not `default`):
#   - The proof loop on otech102 surfaced a 502 status-read-failed:
#     "User \"system:serviceaccount:catalyst-system:default\" cannot get
#     resource \"configmaps\" in API group \"\" in the namespace \"catalyst\""
#     because no Role/ClusterRole was bound to the default SA. Granting
#     cluster-scope cutover-driver verbs to the default SA would leak
#     those permissions to every other Pod in catalyst-system.
#   - Per docs/INVIOLABLE-PRINCIPLES.md #10 (least privilege), bespoke
#     workload SAs are the canonical pattern. This SA is referenced
#     explicitly in api-deployment.yaml's spec.serviceAccountName.
apiVersion: v1
kind: ServiceAccount
metadata:
  name: catalyst-api-cutover-driver
  labels:
    app.kubernetes.io/name: catalyst-api
    app.kubernetes.io/component: cutover-driver-sa
