{{- /*
Object Storage credentials secret — bridges the canonical
flux-system/object-storage Secret (issue #371, vendor-agnostic since
#425) into the velero namespace in the INI format that
velero-plugin-for-aws expects at /credentials/cloud (mounted via
AWS_SHARED_CREDENTIALS_FILE in the upstream chart's deployment.yaml).

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 Velero chart's `existingSecret` field expects a Secret in
the workload namespace (velero), NOT in flux-system, with a single key
`cloud` containing the AWS-CLI shared-credentials file format:

  [default]
  aws_access_key_id=<KEY>
  aws_secret_access_key=<SECRET>

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/34-velero.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 Velero runs without S3 backup).
  - .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
    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-velero.objectStorageCredentialsSecretName" . }}
  namespace: {{ .Release.Namespace }}
  labels:
    {{- include "bp-velero.labels" . | nindent 4 }}
  annotations:
    catalyst.openova.io/comment: |
      AWS-CLI INI shape derived from flux-system/object-storage
      via Flux valuesFrom. Mounted into the velero pod at
      /credentials/cloud by the upstream chart's existingSecret path.
type: Opaque
stringData:
  cloud: |
    [default]
    aws_access_key_id={{ $accessKey }}
    aws_secret_access_key={{ $secretKey }}
{{- end }}
