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

# 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](https://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:

```bash
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):

```bash
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

```bash
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.