Skip to content

fix: harden production database recovery path - #134

Merged
abrichr merged 1 commit into
mainfrom
codex/production-db-backup-readiness
Aug 20, 2026
Merged

fix: harden production database recovery path#134
abrichr merged 1 commit into
mainfrom
codex/production-db-backup-readiness

Conversation

@abrichr

@abrichr abrichr commented Aug 20, 2026

Copy link
Copy Markdown
Member

Summary

  • route the plaintext production database dump only to the workflow-restricted production-backup self-hosted runner group
  • verify the exact live S3 account, region, public-access block, SSE-S3, versioning, ownership, lifecycle, TLS, and encryption policy before backup, monitoring, or restore
  • bind all S3 object calls to expected bucket owner 992382684924
  • normalize only the random PostgreSQL restrict/unrestrict guard outside COPY data during scratch redump comparison, while retaining raw and comparison digests in v2 restore evidence
  • align the least-privilege IAM reads, runbooks, and regression tests

Read-only production preflight

The audit used AWS_PROFILE=openadapt and verified AWS account 992382684924 before each AWS result. The reviewed CloudFormation template validates. The production database backup stack does not exist. No backup-named S3 bucket, IAM role, or GitHub OIDC provider exists in that account.

The production Supabase project is active in us-east-1. It reports no available physical backup and PITR disabled. The production-backup and production-backup-monitor GitHub environments have no settings or branch policies. Main is not protected. No repository self-hosted runner exists. The scheduled backup and freshness workflows therefore fail safely before database or S3 access. Issues #132 and #130 retain the durable alerts.

This database recovery bucket is separate from the held Execute acceptance evidence store. This template does not enable S3 Object Lock. This work created no AWS resource, changed no GitHub environment, and dispatched no backup.

Required operating boundary

Before the first dispatch, an organization administrator must restrict the production-backup runner group to this repository and the exact db-backup.yml workflow on refs/heads/main. The runner must be ephemeral, use an encrypted clean work volume inside the declared production data boundary, and belong only to that group. A GitHub-hosted runner or an unrestricted self-hosted runner must not process the plaintext database.

The first backup still requires protected main, exact main-only environment policies, the reviewed stack in AWS account 992382684924, the six environment settings, a second protected copy of the age private key, one successful backup plus freshness check, and an isolated database-plus-Storage restore drill.

Validation

  • actionlint: pass
  • shellcheck: pass
  • pytest: 201 passed
  • documentation validation: pass
  • strict MkDocs build: pass
  • AWS CloudFormation validate-template: pass in verified account 992382684924

Related: #130, #132

@abrichr
abrichr merged commit dbc110c into main Aug 20, 2026
5 checks passed
@abrichr
abrichr deleted the codex/production-db-backup-readiness branch August 20, 2026 15:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant