{{- /*
Object Storage credentials secret — bridges the canonical
flux-system/object-storage Secret (issue #371, vendor-agnostic since
#425) into the harbor namespace in the format the upstream Harbor
registry deployment expects when
`persistence.imageChartStorage.s3.existingSecret` is set.

Per ADR-0001 §13 (S3-aware app architecture rule):
  S3-aware app (Harbor, Velero, ...) → cloud-provider native S3
  (Hetzner Object Storage on Hetzner Sovereigns; AWS S3 on AWS
  Sovereigns; Azure Blob via S3 endpoint on Azure; etc.)

Per #425 the values block is vendor-AGNOSTIC: `.Values.objectStorage
.s3.{accessKey,secretKey}` carry the credentials regardless of which
cloud provisions them. The Sealed Secret name is ALSO vendor-agnostic
(`flux-system/object-storage`) so a future AWS / Azure / GCP / OCI
Sovereign reuses this exact chart with no rename — only the
`infra/<provider>/` Tofu module changes.

The upstream Harbor chart's
`persistence.imageChartStorage.s3.existingSecret` field expects a
Secret in the harbor namespace with TWO keys consumed by the registry
pod via envFrom:

  REGISTRY_STORAGE_S3_ACCESSKEY=<KEY>
  REGISTRY_STORAGE_S3_SECRETKEY=<SECRET>

(See charts/harbor/templates/registry/registry-dpl.yaml +
 charts/harbor/templates/registry/registry-secret.yaml in the upstream
 1.18.3 chart for the consumption path.)

Per docs/INVIOLABLE-PRINCIPLES.md #4 (never hardcode), values are
sourced from operator-supplied overlay values (`.Values.objectStorage
.s3.accessKey` / `.secretKey`), which the per-Sovereign HelmRelease
populates via Flux `valuesFrom` against flux-system/object-storage
Secret. See the bootstrap-kit slot
clusters/_template/bootstrap-kit/19-harbor.yaml for the canonical
mapping (s3-access-key → objectStorage.s3.accessKey, etc.).

Per docs/INVIOLABLE-PRINCIPLES.md #10 (credential hygiene):
  - The plaintext keys exist only inside this rendered Secret + the
    pod's tmpfs mount. They never land in chart values committed to
    git (Flux interpolates them from the source Secret at apply time).
  - Default render with empty values produces no Secret (skip branch
    via `if .Values.objectStorage.enabled`), which is what
    `helm template` against contabo (no Hetzner credentials) emits.

Operator override paths:
  - .Values.objectStorage.enabled: false skips this template entirely
    (e.g. on contabo where Harbor runs with type: filesystem).
  - .Values.objectStorage.useExistingSecret: true reuses an operator-
    supplied Secret already present in the namespace (sealed-secret /
    external-secret / etc.) — chart skips creation, upstream chart's
    persistence.imageChartStorage.s3.existingSecret reference still
    wires through.
*/ -}}
{{- if and .Values.objectStorage.enabled (not .Values.objectStorage.useExistingSecret) }}
{{- $accessKey := .Values.objectStorage.s3.accessKey | default "" -}}
{{- $secretKey := .Values.objectStorage.s3.secretKey | default "" -}}
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "bp-harbor.objectStorageCredentialsSecretName" . }}
  namespace: {{ .Release.Namespace }}
  labels:
    {{- include "bp-harbor.labels" . | nindent 4 }}
  annotations:
    catalyst.openova.io/comment: |
      REGISTRY_STORAGE_S3_{ACCESSKEY,SECRETKEY} envFrom shape derived
      from flux-system/object-storage via Flux valuesFrom. Wired into
      the upstream Harbor registry pod via
      persistence.imageChartStorage.s3.existingSecret.
type: Opaque
stringData:
  REGISTRY_STORAGE_S3_ACCESSKEY: {{ $accessKey | quote }}
  REGISTRY_STORAGE_S3_SECRETKEY: {{ $secretKey | quote }}
{{- end }}
