Files

T

ehoandClaude Sonnet 5 f21c3c7ca2 docs(backlog): add phase 10 (OpenZaak hardening) and phase 11 (behandelportal)

WP-55..60 harden the OpenZaak integration for production (secrets/TLS,
idempotent provisioning, least-privilege scopes, real notifications,
confidentialiteit config, write-divergence resilience). WP-61..66 stand up
a staff-facing behandelportal per ADR-0002, wired to the same backend via
BFF-lite decision DTOs. Both phases are independent tracks; WP-60's
Decisions block is deliberately left open for a planner-agent kickoff.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-30 11:59:11 +02:00

2.9 KiB

Raw Blame History

WP-55 — Real secrets + TLS for the OpenZaak harness

Status: todo Phase: 10 — OpenZaak production hardening

Why

backend/openzaak/docker-compose.openzaak.yml is explicitly a throwaway dev/test harness: SECRET_KEY: wp-54-local-harness-not-for-prod, POSTGRES_HOST_AUTH_METHOD=trust (no DB password), IS_HTTPS: 'no', DISABLE_2FA: 'true'. Before anything else in this phase can be called "production," the instance needs real secrets, real DB auth, and TLS. The BFF side is already fine — ZgwOptions.cs binds from IConfiguration, so this is a deploy-config change, not application code.

Read first

Decisions (pre-made, don't relitigate)

Secrets come from the deployment environment (env vars / secrets manager), never checked into compose or appsettings.
TLS termination happens at a reverse proxy/ingress in front of OpenZaak — OpenZaak itself doesn't need built-in cert handling.
The existing dev harness stays as-is for local iteration (WP-54's trimmed rig is intentional and still valuable); this WP adds a production compose/override or an env-driven parameterization of the same file, not a replacement of the dev rig.

Files

backend/openzaak/docker-compose.openzaak.yml (or a new docker-compose.openzaak.prod.yml override)
backend/openzaak/README.md
backend/src/BigRegister.Api/appsettings*.json / Zgw/ZgwOptions.cs (confirm only, likely no change)

Steps

Parameterize SECRET_KEY, DB user/password, and the ZGW JWT secret via env vars; remove hardcoded values from the committed file.
Switch POSTGRES_HOST_AUTH_METHOD from trust to password auth, password from env.
Set IS_HTTPS: 'yes'; document the required reverse-proxy/ingress TLS termination.
Update backend/openzaak/README.md with the required env vars and the TLS note.
Confirm the BFF's JWT secret already comes from config — no code change expected.

Acceptance criteria

No secret value is hardcoded in any committed compose/config file.
The production compose fails fast (or docs state clearly) when secrets aren't supplied — no silent fallback to a real-looking default.
README documents exactly which env vars must be set and how TLS is terminated.

Verification

docker compose -f backend/openzaak/docker-compose.openzaak.yml config with required env vars set; cd backend && dotnet test (WP-54 harness tests unaffected); manual: the local dev harness still works with its dev-only values documented as dev-only.

Out of scope

Catalogus provisioning (WP-56), client scope narrowing (WP-57), notifications (WP-58).

Risks

If TLS/secrets docs lag an actual deploy, someone could ship with dev defaults — mitigate by making the prod compose fail without required env vars rather than silently defaulting.

2.9 KiB Raw Blame History