Repository navigation
Isolate wedding database backups with a dedicated R2 identity #2867
Description
🤖 Generated by the Agentic Engineer
Problem
The wedding database backup currently consumes the platform-wide backup identity. A prior draft changed the secret path without provisioning a distinct credential, so a fresh rebuild would lose backup access while the original credential scope remained unchanged.
Impact
A tenant-scoped backup consumer should not inherit access to unrelated platform backups. Renaming the secret path alone does not reduce that access and creates an unrecoverable disaster-recovery dependency.
Expected outcome
Give the wedding database backup its own durable R2 destination and identity, with declarative bootstrap and recovery. Cloudflare permanent R2 identities are bucket-scoped rather than prefix-scoped, so the design must use a dedicated bucket or an equivalently isolated mechanism.
Acceptance criteria
- A dedicated production R2 destination and Object Read and Write identity are created with no access to the shared backup destination.
- The distinct destination and credential are stored through the existing encrypted per-environment bootstrap flow and seeded into OpenBao on a from-zero rebuild.
- Local MinIO exercises the same manifest and secret-delivery path without requiring production credentials.
- CI proves the wedding ExternalSecret references a declaratively seeded dedicated path and the ObjectStore references the dedicated destination.
- A live backup and restore are demonstrated with the new identity, and denial against the shared destination is verified before the old access path is retired.
- The disaster-recovery and rotation runbooks cover the additional destination and credential lifecycle.
Part of #2043.
Decomposed 2026-08-19 into three sequenced sub-issues (real sub-issue links, with native
blocked-by dependencies rather than nesting):
- Provision a dedicated R2 bucket and identity for the wedding database backup #3251 — provision the dedicated bucket + Object Read/Write identity
- Seed the dedicated wedding backup credential and repoint the ExternalSecret and ObjectStore #3252 — seed it declaratively and repoint the
ExternalSecret/ObjectStore - Verify the dedicated wedding backup identity, retire shared access, and update the DR runbooks #3253 — verify backup+restore, verify denial against the shared destination, retire old access,
update the DR runbooks
Remaining engineering work — September 8, 2026
The dedicated account-token grant in #3251 was approved and executed. The live probe confirms dedicated-bucket read/write/list/delete access and 403 denial for shared-bucket read/list/write access. Credentials are encrypted in the production bootstrap source; its reviewed handoff is in progress.
The account token and scope proof need no repeated approval. The remaining work is the declarative seed and projection, local fixture and CI proof, atomic backup cutover, backup and isolated restore verification, and recovery/rotation documentation in #3252 and #3253. Keep the existing backup path available until those checks pass.
Delivery status — September 8: the encrypted public-source publication question is answered and PR3690 is open for the reviewed staging delivery. No personal action is required. The remaining source integration, seed and projection checks, local fixture proof, backup cutover, isolated restore, and runbooks remain engineering work under #3252 and #3253.
Blocker: none — nothing outside the portfolio blocks this (re-read 2026-10-04). #3252 closed 2026-10-02; the remaining work is #3253 (observed denial, shared-access retirement, runbooks), recorded as a native dependency. Keep shared recovery access available until #3253 passes.
Activity
coderabbitai commentedon Aug 1, 2026
🔗 Related PRs
#2735 - fix(velero): isolate kopia repository password [merged]
#3245 - security(minio): import the bucket Job's credential from a file instead of the environment [merged]
#3203 - security(vault-backup): disposition the last two CKV_K8S_40 findings as one deferred exception [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 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:💬 Have feedback or questions? Drop into our discord!
devantler commentedon Oct 5, 2026
The dedicated-backup outcome is delivered. #3251, #3252 and #3253 are closed; their receipts cover provisioning, declarative bootstrap, local/CI projection, isolated restore, observed shared-destination denial and retirement. Protected main runs 37234932425 and 37240640725 provide the denial and post-retirement backup evidence.
Fresh production readback on 2026-10-05 confirms a healthy active archiver, only the dedicated ObjectStore and backup credential projection, and a completed post-retirement backup at 2026-10-04T22:39:54Z. The stale parent blocker on #3253 no longer applies.
Closing the delivered umbrella. #4481 still owns safe retirement of the old shared catalogue, and #4482 owns repair of the rerunnable rotation proof and finished cutover tooling; neither follow-up is being claimed complete here.