Plan Qonto Kubernetes credential lane

plans/rapp-qonto-openbao-kubernetes-lane.md

@@ -0,0 +1,113 @@
+---
+id: rapp-qonto-openbao-kubernetes-lane
+demand_source: reef-railiance/workplans/REEF-RAILIANCE-WP-0003-T01
+consumer_repo: rapp-qonto
+credential_type: openbao-kubernetes-kv
+status: reviewed
+approved_by: null
+approved_at: null
+created: "2026-07-27"
+updated: "2026-07-27"
+---
+
+# Construction plan: rapp-qonto OpenBao Kubernetes lane
+
+## 1. Demand
+
+`rapp-qonto` needs non-interactive, read-only delivery of the existing Binky
+Qonto API credential from `tenants/binky/qonto-api` into its dedicated
+Kubernetes namespace. External Secrets Operator should authenticate to OpenBao
+with Kubernetes workload identity; neither the application nor a
+ClusterSecretStore should hold a long-lived OpenBao token.
+
+## 2. Existing-structure survey
+
+Live OpenBao state was checked on 2026-07-27:
+
+- auth mounts include `kubernetes/`; its configured API endpoint is the
+  cluster-local `https://10.43.0.1:443`;
+- existing Kubernetes roles are `external-secrets-activity-core`,
+  `external-secrets-issue-core`, and `external-secrets-reuse-surface`;
+- policy `workload-kv-read-binky-qonto-api` already exists and is scoped to
+  the existing tenant credential;
+- the `tenants/` KV v2 mount and `tenants/binky/qonto-api` value already
+  exist; this plan does not create or read the value;
+- existing cluster stores use an interim static-token pattern, despite the
+  Kubernetes roles existing;
+- `CCR-2026-0009` proposed a duplicate
+  `workload-kv-read-qonto-assistant` policy and the transitional
+  `qonto-assistant` namespace/name.
+
+The existing read policy satisfies the requested data scope exactly. Reuse it;
+do not create the duplicate policy from CCR-2026-0009. A new authentication
+role is still required because no existing role should gain Qonto access and
+no existing Qonto lane is workload-authenticated.
+
+## 3. Proposed changes
+
+| # | Action | Object | Reuse-vs-new rationale |
+|---|---|---|---|
+| 1 | reuse | policy `workload-kv-read-binky-qonto-api` | Already grants the exact required read scope; a second equivalent policy adds drift without isolation |
+| 2 | create | Kubernetes auth role `external-secrets-rapp-qonto` | New identity binding only; bound to service account `external-secrets` in namespace `external-secrets`, policy #1, token TTL 15 minutes |
+| 3 | create | `ClusterSecretStore/openbao-rapp-qonto` | Uses Vault Kubernetes auth role #2 and the `tenants` KV v2 mount; namespace condition permits only `rapp-qonto` |
+| 4 | modify | `rapp-qonto` ExternalSecret | Map remote fields `API_USER` -> `QONTO_LOGIN` and `API_KEY` -> `QONTO_SECRET_KEY`; no values enter Git or logs |
+| 5 | retire | proposed `openbao-qonto-assistant` static-token store | Superseded before deployment; avoids a long-lived OpenBao token in a Kubernetes Secret |
+| 6 | propose | ops-warden catalog entry `rapp-qonto-workload-kv` | Pointer to the built Kubernetes-auth lane, `warden_executes: false`, initially `draft` |
+
+No underlying Qonto secret is created, changed, printed, or rotated.
+
+## 4. Review notes
+
+- **Naming:** steady-state `rapp-qonto` names replace the migration-only
+  `qonto-assistant` names.
+- **TTL/scoping:** 15-minute tokens match existing External Secrets roles.
+  The role binds only the ESO service account; the ClusterSecretStore
+  condition restricts consumers to one namespace.
+- **Redundancy:** reuses the exact existing policy. This removes the duplicate
+  policy proposed by CCR-2026-0009.
+- **Compaction:** the draft static-token Qonto store is retired before it is
+  deployed. Existing unrelated stores are untouched.
+- **Consumer usability:** External Secrets performs authentication and
+  delivery. The application consumes only a namespaced Kubernetes Secret.
+- **Posture:** the lane accesses a high-risk bank credential, but it is
+  read-only and the runtime exposes no financial write operation. Production
+  still requires egress, audit, revocation, and failure-domain gates.
+- **Build executor extension:** ops-mason currently builds AppRole lanes only.
+  Phase 4 must add a narrowly tested Kubernetes-role operation with the same
+  approval refusal and metadata-only audit guarantees before applying this
+  plan.
+
+## 5. Executive summary
+
+**One-line ask:** allow External Secrets on railiance01 to deliver the existing
+Binky Qonto read credential to `rapp-qonto` without storing a long-lived
+OpenBao token in Kubernetes.
+
+**Who/what gets access:** a new OpenBao Kubernetes role named
+`external-secrets-rapp-qonto`, usable only by the existing
+`external-secrets` service account in the `external-secrets` namespace. No
+application pod, human role, or unrelated service account receives OpenBao
+login rights.
+
+**To what:** read-only access through the existing
+`workload-kv-read-binky-qonto-api` policy to exactly
+`tenants/binky/qonto-api`. Store use is limited to ExternalSecret resources in
+the `rapp-qonto` namespace.
+
+**For how long:** each Kubernetes-auth login receives a 15-minute OpenBao
+token. There is no delivered AppRole secret ID and no long-lived OpenBao token
+stored in Kubernetes. The Kubernetes service-account identity remains valid
+while the ESO deployment and role binding exist.
+
+**Blast radius if the identity is abused:** an attacker able to act as the ESO
+service account and use this role could read the Binky Qonto API credential.
+The OpenBao policy cannot read any sibling tenant secret. The downstream Qonto
+key remains high-risk and must be rotated if exposed.
+
+**Cost to reverse:** delete one Kubernetes auth role, one ClusterSecretStore,
+and the `rapp-qonto` ExternalSecret/derived Secret. The existing human Qonto
+lane and underlying credential remain intact; no unrelated consumer changes.
+
+**Decision needed:** approve as proposed, reject, or send back to phase 1 with
+changes. Approval authorizes the structural access lane only, never disclosure
+or modification of the Qonto credential value.