---
id: REEF-RAILIANCE-WP-0003
type: workplan
title: "Complete rapp-qonto production gates"
domain: financials
repo: reef-railiance
status: active
owner: codex
topic_slug: railiance
created: "2026-07-26"
updated: "2026-07-27"
state_hub_workstream_id: "c3f9fbfd-3db1-4387-8b65-7d53ba57138d"
---

# REEF-RAILIANCE-WP-0003 - rapp-qonto production gates

## 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: 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.

## 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.