fix: harden production database recovery path - #134
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
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
Related: #130, #132