feat(tenant): typed per-tenant ExternalSecrets on the KRO Tenant schema

[devantler]

🤖 Generated by the Daily AI Assistant

Part of #1932. Follow-up child from the Tenant-abstraction ADR (docs/tenant-abstraction.md).

Problem

The KRO Tenant RGD emits only the ghcr-auth ExternalSecret. Tenants that need additional secrets (e.g. wedding-app's object-store / db-backup credentials) still hand-write their own ExternalSecret manifests — exactly the boilerplate the abstraction exists to remove.

Proposed direction

Add a typed, optional secrets list to the Tenant schema so a tenant declares the OpenBao/store keys it needs and the RGD renders the corresponding ExternalSecret(s). Preserve the isolation posture verbatim (same store, refresh interval, RBAC). Render-diff vs the current hand-written instances to prove behaviour-preservation.

Rough size

S–M — schema field + RGD template addition + a render-diff parity check against an existing tenant that carries extra secrets.

Acceptance criteria

• Optional secrets input on the Tenant schema (typed; empty ⇒ only ghcr-auth, unchanged).
• RGD renders one ExternalSecret per declared entry, matching the current hand-written shape.
• A tenant migrated to the new field render-diffs clean vs its pre-change manifests.

[coderabbitai]

🔗 Related PRs

#2331 - feat(actual-budget): seed Enable Banking bank-sync via OpenBao/ESO + reconcile sidecar [merged]
#2343 - fix(openbao): grant external-secrets role write/read on apps/actual-budget path [merged]
#2345 - fix(openbao): grant actual-budget the missing vault ACL paths [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Daily AI Assistant

Design-researched this (KRO 0.9.2, the version pinned in k8s/bases/infrastructure/controllers/kro/helm-release.yaml): the "one ExternalSecret per declared entry" AC needs KRO's forEach collections feature (top-level, one ExternalSecret per Tenant.spec.secrets[] entry — well-documented, low-risk, matches the platform's existing single-level includeWhen boolean-toggle pattern) plus a nested CEL .map() producing a list of objects (to turn each entry's keys: []{secretKey, property} into the ExternalSecret's data: list) — e.g. ${secret.keys.map(k, {"secretKey": k.secretKey, "remoteRef": {"key": secret.remoteKey, "property": k.property}}))}.

Blocker for an unattended run: kro has no offline/CLI static validator for CEL expression correctness — RGD schema+CEL validation only happens when the kro controller reconciles the RGD against a live cluster (confirmed via kro's own static-type-checking docs: "you would need to apply it to an active Kubernetes cluster where kro is installed"). ksail workload validate/kubeconform only checks the RGD CR against the ResourceGraphDefinition CRD schema — it does not execute kro's CEL runtime, so it cannot catch a malformed forEach/.map() expression. Shipping this blind would violate the verify-it-works-E2E principle (constitution #2078) — a bad CEL expression would only surface when the maintainer applies it locally.

Disposition: parked for a run with live local-cluster verification budget (apply the updated RGD + a test Tenant instance with a secrets entry to the docker-provider cluster, confirm the rendered ExternalSecret matches wedding-db-backup-r2's shape). Picked up #2522 (ResourceQuota/LimitRange) instead this run — it needs only the already-proven includeWhen-on-object-presence pattern (mirrors the existing sops/externalDns toggles), no forEach/nested-map, so it is safely static-validatable.