railiance-platform/docs/put-backup-object-storage.md

3.2 KiB

Put the scoped backup object-store key (founder, local only)

Do this on a trusted terminal. Do not paste ACCESS_KEY_ID or ACCESS_SECRET_KEY into chat, Git, or State Hub.

CCR: credential-change-requests/CCR-2026-0012-backup-object-storage.yaml
Path: platform/workloads/railiance/backup/object-storage

This is not the bootstrap key (…/scaleway/bootstrap). That key created the bucket. This key is the general backup runtime identity for application resource-control. First consumer is rapp-postgres (Secret platform-pg-backup-s3).

1. Use IAM application resource-control

In console.scaleway.com → IAM → Applications:

  1. Create application resource-control if it does not exist. Do not create a Barman- or postgres-specific application.
  2. Create an API key on that application (not on your user):
    • Description / name: Scoped backup access
    • Preferred Project for Object Storage: the project that owns bucket railiance-platform-pg-backup
  3. Copy the access key and secret key into a local scratch file (chmod 600). The secret is shown once.

Put only backup-scoped keys on this application. Scaleway attaches policies to the application, not to one key. The bootstrap key must stay off resource-control.

2. Bind policy Scoped backup access

IAM → Policies → create (or reuse) Scoped backup access:

  • Principal: application resource-control
  • Scope: that one project, not the whole Organization
  • Permission sets, if the console lists them:
    • ObjectStorageBucketsRead
    • ObjectStorageObjectsRead
    • ObjectStorageObjectsWrite
    • ObjectStorageObjectsDelete
  • If those sets are not listed, ObjectStorageFullAccess on this project only is acceptable because the project should contain only backup buckets.

Do not attach IAM* or compute permission sets.

3. Put the values in OpenBao

On this host, with a token that can write the platform mount:

bao kv put platform/workloads/railiance/backup/object-storage \
  ACCESS_KEY='SCWxxxxxxxx' \
  SECRET_KEY='xxxxxxxx' \
  DEFAULT_ORGANIZATION_ID='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' \
  DEFAULT_PROJECT_ID='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

Same four field names as the bootstrap path. External Secrets projects ACCESS_KEY / SECRET_KEY to Kubernetes ACCESS_KEY_ID / ACCESS_SECRET_KEY.

Optional field for the bucket policy (not a secret):

bao kv patch platform/workloads/railiance/backup/object-storage \
  APPLICATION_ID='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

Copy the UUID from IAM → Applications → resource-control. Then tell the agent “APPLICATION_ID is in bao.” They will run reef-storage/tools/apply-backup-bucket-policy.sh.

4. Confirm without printing values

bao kv metadata get platform/workloads/railiance/backup/object-storage

You should see a current version greater than any placeholder version. Then tell the agent: “the backup key is in bao.”

Do not enable WAL archiving yourself. T04 still has to prove a negative key cannot access the bucket and to vend the first consumer Secret. T05 enables continuous archiving.

After the scoped key works, delete or lock down the bootstrap key from CCR-2026-0011.