Complete Qonto secret delivery gate

This commit is contained in:
codex 2026-07-27 03:14:25 +02:00
parent 0a4f4b9de6
commit 1c679ee421

View file

@ -8,7 +8,7 @@ status: active
owner: codex
topic_slug: railiance
created: "2026-07-26"
updated: "2026-07-26"
updated: "2026-07-27"
state_hub_workstream_id: "c3f9fbfd-3db1-4387-8b65-7d53ba57138d"
---
@ -18,7 +18,7 @@ state_hub_workstream_id: "c3f9fbfd-3db1-4387-8b65-7d53ba57138d"
```task
id: REEF-RAILIANCE-WP-0003-T01
status: progress
status: done
priority: high
state_hub_task_id: "de8a8e05-93f9-4082-bbb0-5b522179421d"
```
@ -26,16 +26,23 @@ state_hub_task_id: "de8a8e05-93f9-4082-bbb0-5b522179421d"
Establish the `rapp-qonto` identity and OpenBao-backed ExternalSecret lane
without exposing credential values.
2026-07-27: ops-mason surveyed live OpenBao state and produced reviewed plan
`rapp-qonto-openbao-kubernetes-lane`. It reuses the existing exact-scope Qonto
policy, replaces the draft static-token store with Kubernetes authentication,
and awaits the mandatory structural-access approval before build.
2026-07-27: Live topology invalidated the original Kubernetes-auth design:
Coulombcore OpenBao cannot validate railiance01 service-account tokens. The
failed objects were removed. The revised, explicitly approved ops-mason plan
`rapp-qonto-openbao-approle-bridge` reuses the existing exact-scope Qonto
policy and establishes a transitional AppRole bridge with 15-minute tokens,
30-minute maximum TTL, eight uses, and a revocable bootstrap identity held by
ESO. Live metadata-only verification reports
`ClusterSecretStore/openbao-rapp-qonto` `Valid`,
`ExternalSecret/rapp-qonto` `SecretSynced`, and exactly two keys in the
derived Secret. No credential value was exposed. Same-cluster Kubernetes auth
remains the migration target.
## T02 - Enforce restricted Qonto egress
```task
id: REEF-RAILIANCE-WP-0003-T02
status: todo
status: progress
priority: high
state_hub_task_id: "2a6742f1-6fcf-4164-b885-a7a9ea39521d"
```