[Task] Implement supported ingress, TLS, and public-route deployment profiles #24

Closed
opened 2026-07-30 15:27:31 +02:00 by zemion · 2 comments
Owner

Context

The deployment compiler can bind the generated Web service to a host endpoint, but a self-hosted installation still needs an explicit, supportable public-route boundary. Requiring an HTTPS public_url without configuring or validating ingress would create a misleading production path.

Parent user story: GovOPlaN/govoplan#13

Scope

  • Model an existing reverse proxy and a supported managed ingress as explicit installation choices.
  • Define trusted proxy networks, forwarded-header handling, HTTP-to-HTTPS behavior, certificate issuance/renewal, and public health checks.
  • Keep TLS/private key material out of installation.json, plans, logs, and the browser.
  • Make reconfiguration preserve certificates and reject unsafe proxy trust ranges.
  • Document DNS and externally reachable port prerequisites.
  • Add offline render tests and a container integration test for the managed profile.

Acceptance criteria

  • A self-hosted install cannot apply until one supported ingress mode is configured and validated.
  • Existing-proxy mode emits exact proxy/upstream settings and verifies the public route.
  • Managed-ingress mode provisions persistent certificate state and renewal health.
  • doctor distinguishes local upstream health, TLS validity, DNS resolution, and public reachability.
  • No runtime application container receives ingress-only secrets.
  • Reconfiguration and rollback behavior are covered by tests and operator documentation.
## Context The deployment compiler can bind the generated Web service to a host endpoint, but a self-hosted installation still needs an explicit, supportable public-route boundary. Requiring an HTTPS `public_url` without configuring or validating ingress would create a misleading production path. Parent user story: GovOPlaN/govoplan#13 ## Scope - Model an existing reverse proxy and a supported managed ingress as explicit installation choices. - Define trusted proxy networks, forwarded-header handling, HTTP-to-HTTPS behavior, certificate issuance/renewal, and public health checks. - Keep TLS/private key material out of `installation.json`, plans, logs, and the browser. - Make reconfiguration preserve certificates and reject unsafe proxy trust ranges. - Document DNS and externally reachable port prerequisites. - Add offline render tests and a container integration test for the managed profile. ## Acceptance criteria - [ ] A self-hosted install cannot apply until one supported ingress mode is configured and validated. - [ ] Existing-proxy mode emits exact proxy/upstream settings and verifies the public route. - [ ] Managed-ingress mode provisions persistent certificate state and renewal health. - [ ] `doctor` distinguishes local upstream health, TLS validity, DNS resolution, and public reachability. - [ ] No runtime application container receives ingress-only secrets. - [ ] Reconfiguration and rollback behavior are covered by tests and operator documentation.
Author
Owner

Boundary clarification after the local load-balancing slice (pending push): the installer now provisions an internal HTTP HAProxy that balances WebUI/API Compose replicas and owns the host listen port. This does not satisfy this issue: it does not terminate TLS, issue/renew certificates, validate DNS/public reachability, or model an existing reverse proxy versus managed ingress.

Keeping #24 open with its current acceptance criteria. The new scaling documentation calls this distinction out explicitly.

Boundary clarification after the local load-balancing slice (pending push): the installer now provisions an internal HTTP HAProxy that balances WebUI/API Compose replicas and owns the host listen port. This does **not** satisfy this issue: it does not terminate TLS, issue/renew certificates, validate DNS/public reachability, or model an existing reverse proxy versus managed ingress. Keeping #24 open with its current acceptance criteria. The new scaling documentation calls this distinction out explicitly.
Author
Owner

Implemented and pushed in 2c515f7. Self-hosted apply now fails closed until existing-proxy or managed Caddy ingress is configured. Existing-proxy mode emits an exact upstream/header contract and trusts only bounded source CIDRs; managed mode owns HTTP-to-HTTPS, persistent ACME state, and no application-visible TLS material. doctor now reports DNS, TLS lifetime, public readiness, host ports, and private upstream health separately. Forwarded headers are normalized through HAProxy/WebUI, ingress/trust artifacts participate in checksum-verified rollback snapshots, operator documentation is updated, and the protected runtime workflow includes digest-pinned Caddy plus HAProxy container validation. Verification: 48 focused deployment/distribution tests plus 2 subtests, Ruff, py_compile, JSON/YAML parsing, and a rebuilt standalone zipapp. The first real public release/topology execution is intentionally retained as target evidence under #37.

Implemented and pushed in `2c515f7`. Self-hosted apply now fails closed until `existing-proxy` or managed Caddy ingress is configured. Existing-proxy mode emits an exact upstream/header contract and trusts only bounded source CIDRs; managed mode owns HTTP-to-HTTPS, persistent ACME state, and no application-visible TLS material. `doctor` now reports DNS, TLS lifetime, public readiness, host ports, and private upstream health separately. Forwarded headers are normalized through HAProxy/WebUI, ingress/trust artifacts participate in checksum-verified rollback snapshots, operator documentation is updated, and the protected runtime workflow includes digest-pinned Caddy plus HAProxy container validation. Verification: 48 focused deployment/distribution tests plus 2 subtests, Ruff, py_compile, JSON/YAML parsing, and a rebuilt standalone zipapp. The first real public release/topology execution is intentionally retained as target evidence under #37.
zemion removed the codex/ready
status
ready
labels 2026-08-03 01:16:36 +02:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan#24