approve: CCR-2026-0012; verify scoped backup key in OpenBao

Founder put ACCESS_KEY/SECRET_KEY. S3 prefix CRUD works. IAM write
and ESO apply remain gated. WAL not enabled.

credential-change-requests/CCR-2026-0012-backup-object-storage.yaml

@@ -3,7 +3,7 @@ kind: credential-change-request
 schema_version: 1
 request_type: workload-kv-read
 title: Scaleway scoped backup object-storage key
-status: proposed
+status: approved
 created: '2026-08-14'
 updated: '2026-08-14'
 requester:
@@ -18,7 +18,13 @@ review:
   required: true
   required_approvers:
   - platform-operator
-  comments: []
+  comments:
+  - at: '2026-08-14T17:30:00+00:00'
+    reviewer: bernd.worsch
+    decision: approved
+    comment: >-
+      Approved in chat (Grok session): CCR-2026-0012 and “the backup
+      key is in bao.” Founder used ACCESS_KEY/SECRET_KEY field names.
 target:
   domain: financials
   tenant: railiance
@@ -27,16 +33,19 @@ target:
   environment: production
   purpose: >-
     Object-store credentials for Railiance backup destinations.
-    Secret keys ACCESS_KEY_ID and ACCESS_SECRET_KEY. APPLICATION_ID
-    is the resource-control IAM application (for a later bucket
-    policy). Endpoint, bucket, prefix, and region stay on reef-storage.
+    Secret keys ACCESS_KEY and SECRET_KEY (projected to Kubernetes as
+    ACCESS_KEY_ID / ACCESS_SECRET_KEY). Org and project ids are
+    non-secret companions. APPLICATION_ID can be added later for a
+    bucket policy. Endpoint, bucket, prefix, and region stay on
+    reef-storage.
 openbao:
   mount: platform
   kv_path: platform/workloads/railiance/backup/object-storage
   fields:
-  - ACCESS_KEY_ID
-  - ACCESS_SECRET_KEY
-  - APPLICATION_ID
+  - ACCESS_KEY
+  - SECRET_KEY
+  - DEFAULT_ORGANIZATION_ID
+  - DEFAULT_PROJECT_ID
   policy_name: workload-kv-read-backup-object-storage
   policy_file: openbao/policies/workload-kv-read-backup-object-storage.hcl
   auth:
@@ -56,15 +65,16 @@ access_frontdoor:
   type: ops-warden
   catalog_id: backup-object-storage
   selector: resource-control scoped backup access
-  command: warden access backup-object-storage --fetch ACCESS_KEY_ID
+  command: warden access backup-object-storage --fetch ACCESS_KEY
   resolvable: false
-  readiness: pending-review
+  readiness: approved-pending-apply
 delivery:
   surface: external-secrets
   target: >-
     ClusterSecretStore openbao-backup-object-storage (first namespace
     condition: databases) → ExternalSecret databases/platform-pg-backup-s3
-    → Secret platform-pg-backup-s3 (consumer projection). Drafts live
+    → Secret platform-pg-backup-s3 (ACCESS_KEY_ID / ACCESS_SECRET_KEY
+    projected from ACCESS_KEY / SECRET_KEY). Drafts live
     under railiance-platform/argocd/platform-addons/openbao-secretstore/
     and rapp-postgres/helm/platform-pg-backup-s3.externalsecret.yaml.
     Do not apply until this CCR is approved and the KV values are real.
@@ -83,8 +93,9 @@ risk:
 verification:
   positive:
   - Field names present on the KV path; values not printed.
-  - An approved databases-namespace ExternalSecret can sync ACCESS_KEY_ID
-    and ACCESS_SECRET_KEY to Secret platform-pg-backup-s3.
+  - An approved databases-namespace ExternalSecret can project ACCESS_KEY
+    and SECRET_KEY to Secret platform-pg-backup-s3 as ACCESS_KEY_ID and
+    ACCESS_SECRET_KEY.
   - The scoped key can list/put/delete backup prefixes on the procured
     bucket.
   negative:
@@ -96,7 +107,7 @@ verification:
   - Platform-operator approves this CCR.
   - Founder creates or reuses IAM application resource-control, binds
     policy Scoped backup access, mints the API key of that name, then
-    replaces OpenBao placeholders.
+    puts ACCESS_KEY and SECRET_KEY in OpenBao. Done 2026-08-14.
   - ESO store and ExternalSecret applied only after values are real.
 lifecycle:
   deactivate: Disable the catalog entry, delete consumer ExternalSecrets,