9ab00f0dff
WP-0003 only updates the binding. WP-0004 takes the RMASTER-WP-0023 grants. Production approval does not make Qonto public.
149 lines
6.5 KiB
Markdown
149 lines
6.5 KiB
Markdown
---
|
|
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`.
|