reef-railiance/workplans/REEF-RAILIANCE-WP-0003-rapp-qonto-production-gates.md
codex 9ab00f0dff chore: narrow Qonto gates and file exposure-grant workplan
WP-0003 only updates the binding. WP-0004 takes the RMASTER-WP-0023
grants. Production approval does not make Qonto public.
2026-08-15 20:52:04 +02:00

6.5 KiB

id type title domain repo status owner topic_slug created updated related state_hub_workstream_id
REEF-RAILIANCE-WP-0003 workplan Complete rapp-qonto production gates financials reef-railiance blocked codex railiance 2026-07-26 2026-08-15
RAIL-BS-WP-0007
RMASTER-WP-0023
ADR-0006
ADR-0008
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

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

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

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

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.