chore(backup): R2 credentials for the off-cluster DR target

Written by platform/backup/set-r2-credentials.sh (operator, 2026-09-07T05:41:34Z)
into all four consumers, in the two shapes they need: velero wants an AWS INI
file, CNPG/barman wants discrete ACCESS_KEY_ID / ACCESS_SECRET_KEY. All four
verified to carry the SAME 32-character key id, so no consumer was missed.

Proven from a pod INSIDE prod against
https://7ce452a1b3d6c86daf2c020edcb82d37.r2.cloudflarestorage.com:
head-bucket on k3s-prod-backup returns BucketRegion WNAM, and PUT and DELETE both
succeed. Byte-integrity of GET is NOT yet proven (the aws-cli image has no cmp);
s3check is what will establish it.

Credentials only — no endpoint or bucket wiring. That is feat/r2-backup-prod.

Co-Authored-By: Claude Opus 5 <[email protected]>

infra/PHASE1-STATUS.md

@@ -84,6 +84,9 @@ toolchain: yamllint, check-jsonschema, kyverno, chainsaw, yq) lives in the image
 infra/devcontainer/dev.sh build                    # once
 infra/devcontainer/dev.sh run make -C ci gate      # exactly what CI runs
 infra/devcontainer/dev.sh                          # interactive shell at /work
+
+infra/devcontainer/dev.sh run kubectl get nodes                # DEV (the default)
+CLUSTER=prod infra/devcontainer/dev.sh run kubectl get nodes   # PROD
 ```
 
 Unlike the libvirt era, **tofu and ansible now run fine inside the container** — the
@@ -95,10 +98,23 @@ which is what broke the old `dmacvicar/libvirt` provider in a container.
 file, and the sibling spec repo read-only at `/home-network-k3s` so the spec-immutability
 check runs instead of silently skipping.
 
-> **Known gap.** `dev.sh` defaults `KUBECONFIG` to `/work/infra/ansible/.cache/dev.kubeconfig`,
-> a libvirt-era path that no longer exists, and does not mount `~/.kube`. In-container `kubectl`
-> therefore needs an explicit `DEV_KUBECONFIG=<path to a break-glass cert kubeconfig>` — the OIDC
-> context cannot work there anyway (no browser). Not yet fixed.
+> **Closed (was a known gap): `dev.sh` can now target either cluster.** It used to hard-wire
+> `KUBECONFIG` to `dev.kubeconfig`, leaving an undocumented — and misleadingly named —
+> `DEV_KUBECONFIG=<prod path>` as the only route to prod. Select with **`CLUSTER=dev|prod`**;
+> **dev remains the default**, so every existing invocation means what it always meant. Inside the
+> container `KUBECONFIG` is a chain of a tiny per-invocation selector file over a merged config
+> carrying both clusters as contexts **`k3s-dev`** and **`k3s-prod`** (never `default`), regenerated
+> each run by [`infra/devcontainer/kubeconfig.sh`](devcontainer/kubeconfig.sh) into the gitignored
+> `infra/ansible/.cache/clusters.kubeconfig`. The merged file deliberately carries **no**
+> `current-context`: it is shared by every container, and stamping the current cluster into it made
+> concurrent `CLUSTER=dev` and `CLUSTER=prod` runs silently swap clusters mid-command. Naming matters: k3s writes *both* source kubeconfigs
+> with context, cluster and user all called `default`, and kubectl's merge keeps the first
+> duplicate — so a plain `KUBECONFIG=dev:prod` would silently resolve `default` to **dev** while you
+> believed you were on prod. Requesting a cluster whose kubeconfig is absent is a hard error, never
+> a fallback. `DEV_KUBECONFIG` still works and still wins, but is **superseded** — it is opaque
+> about its target and yields an ambiguous `default` context. `~/.kube` is still not mounted and the
+> OIDC context still cannot work in a container (no browser); use the break-glass cert kubeconfigs
+> above. Details: [`devcontainer/README.md`](devcontainer/README.md).
 
 ## Off-repo state you must not lose