knative: serving.secretRef → envFrom worker bindings (DECO_BIND_ prefix)

[nicacioliveira]

Why

TanStack-on-Knative sites need runtime env/secrets reaching the worker (site config, OTEL auth, tokens) — like the Deno sites get from the site state today. The workerd runner already bridges DECO_BIND_* pod env into the worker's bindings (infra#237); this wires the operator side.

What

• New spec.serving.secretRef on the Deco CR — a reference to a K8s Secret.
• The operator mounts it on the runner ksvc via envFrom { prefix: DECO_BIND_, secretRef }, so every key becomes env.<KEY> in the worker (mf-run strips the prefix).
• The CR carries only the reference, never the values → portable, secret-free, materializable across clusters.
• Regenerated CRD + deepcopy + chart.

Design (future-ready)

The materializer owns the Secret contents — the admin from siteState today, the control-plane later (per the observability-binding / control-plane RFC). The operator ↔ CR ↔ mf-run contract is unchanged when the source moves. Same pattern as the RFC's Studio binding: control-plane owns the truth, the executor consumes a reference.

Follow-up (admin)

The admin must materialize the <site>-env Secret from siteState and set spec.serving.secretRef in buildProduction — separate PR.

---

Summary by cubic

Add spec.serving.secretRef to the Deco CR and wire it to Knative envFrom with DECO_BIND_, so site env/secrets reach the worker as env.<KEY>. The CR carries only a Secret reference, keeping configs portable and secret-free.

• New Features

  • Optional spec.serving.secretRef on the Deco CR to reference a K8s Secret.
  • Operator mounts the Secret on the runner ksvc via envFrom with DECO_BIND_.
  • Runner exposes each key to the worker as env.<KEY> (prefix stripped).
  • Updated CRDs, deepcopy, and chart.

• Migration

  • Create the Secret (e.g., <site>-env) with required keys and set spec.serving.secretRef during build/deploy.

^{Written for commit fa766eb. Summary will update on new commits.}