4 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated | state_hub_workstream_id |
|---|---|---|---|---|---|---|---|---|---|---|
| REEF-RAILIANCE-WP-0003 | workplan | Complete rapp-qonto production gates | financials | reef-railiance | active | codex | railiance | 2026-07-26 | 2026-07-27 | c3f9fbfd-3db1-4387-8b65-7d53ba57138d |
REEF-RAILIANCE-WP-0003 - rapp-qonto production gates
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: progress
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.
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.