ops-mason/plans/platform-pg-backup-s3.md

id	demand_source	consumer_repo	credential_type	status	approved_by	approved_at	created	updated
platform-pg-backup-s3	resource-control/workplans/RESOURCE-WP-0002-T04	rapp-postgres	openbao-kv-founder-provision	draft	null	null	2026-08-14	2026-08-14

Construction plan: scoped Barman key for platform-pg

1. Demand

RESOURCE-WP-0002 T04 needs a Scaleway API key that can only operate on bucket railiance-platform-pg-backup prefix platform-pg/, stored in OpenBao, and later synced by External Secrets into Kubernetes Secret platform-pg-backup-s3 in namespace databases. CNPG/Barman is the only runtime consumer. Founder mints the key in the Scaleway console (the bootstrap key cannot list application / create IAM). ops-mason builds the empty lane. Values never appear in git or chat.

2. Existing-structure survey

Checked 2026-08-14:

• KV path does not exist. platform/data/workloads/railiance/backup/platform-pg-backup-s3 is 404.
• CCR-2026-0012 reserves that path and fields ACCESS_KEY_ID, ACCESS_SECRET_KEY, APPLICATION_ID. Reuse it. Do not invent a second path.
• CCR-2026-0011 is the bootstrap key (platform/workloads/railiance/scaleway/bootstrap). Different purpose. Do not reuse those values as the runtime key.
• CCR-2026-0004 is Nextcloud/age offsite. Different provider.
• Catalog. No platform-pg-backup-s3 / s3-backup lane.
• Auth. Runtime delivery is External Secrets into databases. Kubernetes auth role external-secrets-platform-pg-backup is the CCR-declared steady state. railiance01 may need the same interim AppRole/token pattern as email-connect / audit-core; that apply is after the founder replaces placeholders.
• Does an existing lane already satisfy this? No live secret.

3. Proposed changes

#	Action	Object	Reuse-vs-new rationale
1	reuse	CCR-2026-0012 path	Already reserved
2	create	policy workload-kv-read-platform-pg-backup-s3	File already written; apply after approval
3	create	empty KV v2 path (placeholders xxx)	Paste-once / UI replace has a home
4	defer	Kubernetes auth role / AppRole / ESO store	After real values exist
5	defer	catalog platform-pg-backup-s3	Pointer only; warden_executes: false until verified
6	defer	Scaleway bucket policy principal	Needs APPLICATION_ID from the founder

No new rail. Scaleway operates S3.

4. Review notes

• Naming: path follows platform/workloads/railiance/backup/…. Policy name matches the CCR.
• TTL/scoping: the Scaleway key is long-lived until rotated. The OpenBao reader is ESO, 15m Kubernetes auth TTL in the CCR.
• Redundancy: does not reuse the bootstrap path or the Nextcloud offsite lane.
• Secret values: mason does not read, write, or log them. Founder uses the OpenBao UI or docs/put-platform-pg-backup-s3.md.
• Founder remaining acts: approve this plan and CCR-2026-0012; create the IAM application and project-scoped key; replace xxx; say “the Barman key is in bao.”

5. Executive summary

One-line ask: approve an OpenBao home for a bucket-scoped Barman key so rapp-postgres can later receive Secret platform-pg-backup-s3 without putting keys in git or chat.

Who gets access: you (founder) to write the three fields; later, only External Secrets bound to namespace databases. No other rapp.

To what: only platform/workloads/railiance/backup/platform-pg-backup-s3 (ACCESS_KEY_ID, ACCESS_SECRET_KEY, APPLICATION_ID). Not the bootstrap path.

For how long: until you rotate or revoke the Scaleway key.

Blast radius if the credential leaks: read/write/delete objects under the backup prefix. Revoke the key in the Scaleway console, delete the KV version, rotate.

Cost to reverse: delete the KV path, policy, and unused drafts. WAL is not enabled yet, so there is no production archive to migrate.

Decision: approve, reject, or send back to phase 1. Approval authorizes structure (empty path, policy). It does not authorize ops-mason to handle the Scaleway secret values, and it does not enable continuous archiving.