railiance-platform/docs/evidence/RPF-WP-0019-isolation-2026-08-20.md

RPF-WP-0019 — apps-pg isolation evidence

Date: 2026-08-20

Live target: railiance01 / databases/apps-pg

Harness: make apps-pg-isolation-probe

The repeatable harness creates a labeled temporary namespace, projects the two existing consumer Secrets into isolated probe pods without printing their values, exercises the real consumer credentials over the service endpoint, and deletes the namespace on exit.

Finding before the passing run

The first privilege preflight found that apps_meta, vergabe_db, and coulomb_social_db retained PostgreSQL's default PUBLIC CONNECT and TEMPORARY privileges. A database-per-consumer declaration was therefore not yet a database connection boundary. The controlled SQL now revokes both privileges from PUBLIC on all three databases and grants them only to each database's owner. The passing run occurred after that correction; the failed precondition is not counted as a pass.

Consumer boundary

All eleven assertions passed:

• each role connected to its own database through the live RW Service;
• each role was denied connection to the peer database;
• coulomb_social was denied connection to apps_meta;
• a consumer could not alter the peer role;
• an own-database table remained readable;
• the real credential observed both 15-second timeouts and connection limit 20; and
• a 20-second statement was terminated by statement_timeout.

Noisy-neighbour run

The harness measured five sequential vergabe queries, filled every available coulomb_social role slot with client-side-idle sessions, verified 20 live connections, and attempted one more connection.

Observation	Result
vergabe baseline, five queries	5,285 ms
coulomb_social at ceiling	20 connections
excess coulomb_social connection	denied
vergabe during saturation, five queries	8,146 ms
measured wall-time increase	54.1%
victim availability	5/5 queries succeeded

The timings include five separate API/exec/process startups, so they are an operator-path comparison rather than an application latency benchmark. Both co-residents declare interactive, but neither declares a numeric database latency objective. The result therefore supports the P1 consumer-boundary and availability claim: one consumer exhausted its own allowance, the control bound, and the peer retained service. It does not establish a latency SLO, CPU fairness, memory fairness, tenant isolation within either consumer, HA, or P2 placement.

Result

14 passed, 0 failed. Production apps-pg remained Ready with continuous archiving and the last backup healthy; deployment/coulomb-social remained 1/1 Ready. The temporary probe namespace was deleted.