Verify the dedicated wedding backup identity, retire shared access, and update the DR runbooks

🤖 Generated by the Agentic Engineer

Evidence

Isolation is only real once the old access path is retired and the new one is proven — and this
touches the disaster-recovery path, so it wants a watched window rather than a merge-and-hope.

docs/dr/runbook.md and docs/dr/velero-cnpg.md both currently document
infrastructure/backup/r2 as the credential behind the wedding database backup, so they go stale the
moment the reference moves.

Expected outcome

A demonstrated backup and restore on the dedicated identity, positive proof that it cannot reach
the shared destination, the old access retired, and the runbooks telling the truth.

Acceptance criteria

A live backup and a live restore are demonstrated using the dedicated identity.
Denial is verified: the dedicated identity is shown to have no access to the shared backup
destination (attempt it and observe the denial — absence of configuration is not proof).
Only after that denial is verified, the wedding tenant's access via the shared credential is
retired.
docs/dr/runbook.md and docs/dr/velero-cnpg.md cover the additional destination and the
credential's rotation lifecycle.

Blocker: none — every acceptance criterion is met (2026-10-04): restore proven, denial observed (run 37234932425), shared access retired by #4483 and confirmed on the live cluster, runbooks updated. Follow-ups: #4481 (old copy in the shared bucket) and #4482 (re-home the denial proof, remove finished cutover tooling).

Part of #2867.

🔗 Related PRs

#2735 - fix(velero): isolate kopia repository password [merged]
#3109 - fix(deploy): avoid redundant GHCR node reboots [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 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!

chore: agent-claim #3253 nonce=becc9a964af4384740128c011a3145df

fix(backup): judge each denial by its trace and by the real mc client

test(backup): pin the pinned mc's recorded refusal output

fix(backup): keep the denial proof's public output and cleanup exact

fix(backup): read the stub's request log as the runner and require a …

fix(backup): pin the stub listing to the catalogue prefix and redact …

🤖 Generated by the Agentic Engineer

Denial observed. The proof from #4364 (tightened by #4388) had merged on 2026-10-02 but had never been dispatched. Run today on protected main:

Run 37234932425 at 3f2764d78b0c5cad91354d21be12baaca28a14d7 (the tip of main at dispatch), first attempt, success.
Receipt: {"dedicatedCatalogueReachable":true,"sharedCatalogueReferenced":true,"listDenied":true,"readDenied":true,"writeDenied":true}
The dedicated credential listed its own catalogue (so the refusals cannot come from a broken key or path), the shared catalogue held the object used as the read target, and the shared destination refused the dedicated credential's list, read and write with an access-denied response. No probe object was left behind.

Acceptance criterion 2 is ticked. Next, in order: retire the wedding tenant's shared access, then finish the two runbooks.

fix(backup): refuse unless retired Wedding shared access is observed …

test(backup): tighten the retired-access fixture and rendered-output …

🤖 Generated by the Agentic Engineer

Shared access is retired, and all four acceptance criteria are met.

Retired: fix(backup): retire the Wedding tenant's access to the shared backup credential #4483 merged through the queue at 2026-10-04 22:34Z (460c0bfa). It removes the shared store and the shared credential projection from the wedding tenant and makes the opt-in live check refuse unless they are observed absent.
Confirmed on the live cluster (read-only, 22:35Z): the namespace holds one backup store, wedding-db-dedicated, and one backup credential projection, the dedicated one. The shared store and the shared projection both read absent, with a positive control on the dedicated projection. The database is 3/3 ready and archiving continuously through the dedicated store.
Backups still work: the fresh-backup proof, run 37240640725 at 460c0bfa, completed with the database stable (backup 20261004T223629).
Runbooks: the rotation scenario, the architecture page and the restore drill describe the dedicated destination, the rotation lifecycle, and which proofs can still run.

One limit, stated plainly: the agent's read-only cluster identity may not read Secrets, so the projected Secret's removal is inferred from its owning projection being gone (it is owned and garbage-collected with it), not observed directly. The opt-in live check in the manual deploy workflow observes it directly the next time it is run.

Left open on purpose: #4481 (the old copy of the wedding backups still sits in the shared bucket) and #4482 (the denial proof and the finished cutover tools need re-homing or removal). Closing this issue.

Navigation Menu

Repository navigation

Verify the dedicated wedding backup identity, retire shared access, and update the DR runbooks #3253

Evidence

Expected outcome

Acceptance criteria

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Verify the dedicated wedding backup identity, retire shared access, and update the DR runbooks #3253

Description

Evidence

Expected outcome

Acceptance criteria

Activity

coderabbitai commented on Aug 19, 2026

devantler commented on Oct 4, 2026

devantler commented on Oct 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions