--- id: REEF-RAILIANCE-WP-0003 type: workplan title: "Complete rapp-qonto production gates" domain: financials repo: reef-railiance status: blocked owner: codex topic_slug: railiance created: "2026-07-26" updated: "2026-08-15" related: - RAIL-BS-WP-0007 - RMASTER-WP-0023 - ADR-0006 - ADR-0008 state_hub_workstream_id: "c3f9fbfd-3db1-4387-8b65-7d53ba57138d" --- # REEF-RAILIANCE-WP-0003 - rapp-qonto production gates This reef records the `rapp-qonto` binding and refuses `production-approved` without ADR-0006 evidence. It does not implement HA (`RAIL-BS-WP-0007`), Knative packaging (`rapp-qonto`), or public listeners. Production approval does not make Qonto public (ADR-0008). New binds stay `private`. Exposure grants for already-public surfaces are `REEF-RAILIANCE-WP-0004`, not this file. ## T01 - Verify workload identity and secret delivery ```task id: REEF-RAILIANCE-WP-0003-T01 status: done priority: high 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: 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: done priority: high state_hub_task_id: "2a6742f1-6fcf-4164-b885-a7a9ea39521d" ``` Implement and verify FQDN-aware policy or a controlled egress proxy. Do not substitute unrestricted HTTPS. 2026-07-27: Implemented a pinned Canonical Squid controlled-proxy candidate that permits `CONNECT` only to exact host `thirdparty.qonto.com:443`, with private-address exclusions and namespace/pod isolation policies. Repository tests and Kubernetes server-side validation passed. Live probes did not: allowlisted proxy access returned `000`, non-allowlisted access returned `000`, and direct Qonto HTTPS unexpectedly succeeded despite namespace default-deny. The candidate was removed from the live cluster and is not included by the runtime Kustomization. T02 remains `progress` until railiance01 NetworkPolicy enforcement is repaired and the three-way probe proves allowlisted success, other-host denial, and direct-bypass denial. 2026-07-27 follow-up: Host firewall-chain tracing showed NetworkPolicy does enforce after kube-router creates the per-pod chain; the failed immediate probe exposed an asynchronous startup window rather than a disabled controller. The runtime now uses an immutable curl init container as a fail-closed startup gate. It retries until its own pod proves Qonto proxy access (`CONNECT 200`), other-host proxy denial (`CONNECT 403`), and direct Qonto denial. Knative init-container support is enabled and source-controlled in `railiance-cluster`. Live disposable-pod evidence reported `gate=passed` before `application=admitted`. The proxy bundle is now part of the active runtime Kustomization and T02 is complete. ## T03 - Deploy and verify rapp-qonto ```task id: REEF-RAILIANCE-WP-0003-T03 status: done priority: high state_hub_task_id: "ddf25c7b-23b0-4e67-8881-5d29fa71e9ad" ``` After T01 and T02, verify cold start, audit, revocation, dependency failure, idempotency, and previous-revision rollback using machine-readable evidence. 2026-07-27: The first application revision is live and ready as `rapp-qonto-00004`; its egress admission gate completed and `/v1/health` passed through the cluster-local Knative service. Full failure, revocation, idempotency, timing, and rollback evidence is still required before T03 can close. 2026-07-29: The reversible `rapp-qonto/tools/verify_live.sh` gate produced machine-readable, secret-free evidence for scale-to-zero, 7.384443-second cold activation, repeat health, ExternalSecret readiness, fail-closed dependency loss, recovery, missing-secret denial, secret restoration, previous-revision rollback, and latest-traffic restoration. The `qonto-assistant` owner suite passes 80 tests covering domain-level audit, idempotency, authorization, and redaction behavior. The reef binding is now `verified`, not `production-approved`. ## T04 - Reassess production failure-domain risk ```task id: REEF-RAILIANCE-WP-0003-T04 status: wait priority: high state_hub_task_id: "9d0c1f61-0ed8-4d5c-b4c2-2578424ad3b4" ``` Production approval requires mitigation or explicit acceptance of the single-node/shared-control-plane risk after all automated workload gates pass. 2026-07-30 reassessment: the reef still exposes exactly one Ready Kubernetes node (`239.62.205.92.host.secureserver.net`). All workload-level gates are green, but no node or control-plane failure domain has been added. This is a real infrastructure availability risk, not stale task bookkeeping. The workplan is therefore `blocked` until either a second independent failure domain is implemented and drilled or the founder explicitly accepts single-node production availability risk for Qonto. The current binding remains accurately `verified`, not `production-approved`. 2026-08-08 alignment: live inspection still reports one Ready node, which also owns the control-plane and etcd roles. `railiance-cluster/RAIL-BS-WP-0007` now owns the required three-server embedded-etcd topology, source-backed node-to-reef failure-domain map, and machine-readable one-server-loss S2 drill. `state-hub/CUST-WP-0038` is a downstream stateful consumer and does not substitute for the Qonto gate. After the S2 drill passes, T04 closes only when the Qonto live verification is rerun with fresh evidence while Railiance01 is absent, proving the service path, restricted egress, identity/secret delivery, dependency behavior, and restoration on the surviving cluster. The alternate closure remains explicit founder acceptance of the single-node production availability risk. This repo only updates `bindings/rapps.yaml` when those conditions hold. Do not implement the three-node topology here. Do not add an exposure grant for Qonto as a side effect of `production-approved`.