ADR-0013: Development-API nutzt Production-PostGIS über PgBouncer mTLS
- Status: accepted
- Datum: 2026-08-26
- Phase: P-SEC / Development
- Lastenheft: INF-04–INF-06, Q-02
Kontext
Production-FastAPI spricht intern postgres:5432 (unpublished). Die Workstation soll Development-Compose bleiben (Bind-Mount, Hot-Reload, Ports 3701/3702), aber dieselbe PostGIS-Instanz wie https://linetra.nasarek.dev sehen. PostGIS darf dafür nicht öffentlich werden.
Entscheidung
Lokales FastAPI/Celery verbindet sich wie QGIS über PgBouncer mTLS (sslmode=verify-full, Client-Zertifikat CN = linetra_edit / linetra_read). DATABASE_HOST ist der öffentliche Hostname (SAN des Server-Zerts). Production-Compose bleibt bei DATABASE_HOST=postgres ohne Client-TLS.
Alembic-DDL und create_app_roles.sh laufen auf dem Server (Superuser geht nicht durch den Proxy).
Begründung
Dasselbe Proxy-Muster wie ADR-0002: Gerät am Zertifikat, PostGIS unsichtbar, Widerruf über die CA. Die Apps bleiben HTTPS zur lokalen FastAPI; nur die API-Container holen sich die DB über den bereits offenen QGIS-Pfad.
Verworfene Alternativen
| Alternative | Warum verworfen |
|---|---|
Editor/Dashboard direkt auf https://linetra.nasarek.dev |
Testet lokale FastAPI-Änderungen nicht gegen Live-Daten |
WireGuard + unpublished :5432 |
VPN-Zwang, widerspricht ADR-0003 |
DATABASE_HOST=linetra.nasarek.dev ohne Client-Zertifikat |
PgBouncer auth_type=cert weist ab |
| Passwort + TLS ohne Client-Zertifikat | Geteiltes linetra_edit, kein Gerätebezug (ADR-0002) |
| Lokales Postgres + Dump-Sync | Daten sind nicht live; Konflikt mit dem Ziel |
Folgen
Compose interpoliert DATABASE_HOST aus .env (Default postgres). Workstation: Zertifikate unter pgbouncer/certs/workstation/ (gitignored), DATABASE_SSLMODE=verify-full. Dateiablage (FILE_STORAGE_DIR) und Redis bleiben lokal — nur die Datenbank ist geteilt.