ADR-006 — Mission Control hosting: Cloudflare Pages behind Cloudflare Access

Status

accepted — 2026-07-03 (decided by: kotsalidis, TPL; access model confirmed by the user in-session)

Context

ADR-005 deliberately stubbed deployment until hosting and access control existed. TPL provided a Cloudflare API token (account with the tpl.one zone and an existing Zero Trust organization, tplgr.cloudflareaccess.com) with the instruction to host the site there and deploy continuously. The site carries data_sensitivity: high content, so public exposure without authentication was not acceptable — the access wall had to exist before the first byte was served.

Decision

1. Hosting: Cloudflare Pages, project vanos-mission-control, production branch master; custom domain vanos.tpl.one attached to the project.
2. Access control first: a Cloudflare Access self-hosted application covers vanos.tpl.one, vanos-mission-control.pages.dev, and *.vanos-mission-control.pages.dev (preview deployments), created before the first deployment. Allow policy: email domains @tpl.gr and @primeltd.com; login via one-time email PIN (the org’s current IdP). Federating to Microsoft Entra ID (per the blueprint) is a planned follow-up, not a blocker.
3. CI/CD: every push to master builds site/ and deploys via cloudflare/wrangler-action; credentials live in GitHub Actions secrets (CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID), approved by the user in-session.
4. Local key handling: the provided key file lives untracked in secrets/ (git-ignored, never committed). It should move into the Prime Products 1Password vault (op:// reference) once that vault exists — standing HANDOFF item.

Consequences

• The blueprint’s hosting assumption (“TPL hosting + oauth2-proxy/Entra”) is amended: Cloudflare Access replaces oauth2-proxy; Entra ID becomes an Access identity provider to add later (needs an Entra app registration from the M365 tenant).
• Preview deployment URLs (*.pages.dev) are also behind Access — safe to share within the allowed domains.
• The tpl.one DNS record for vanos could not be created with the provided token (no Zone.DNS Edit permission) — until the CNAME vanos → vanos-mission-control.pages.dev (proxied) is added, the site is reachable only at the pages.dev hostname. Open item in HANDOFF.
• Cloudflare becomes a hosting dependency for the program’s reporting layer; exit path is trivial (static output deploys anywhere).
• 2026-07-03 correction: the client’s email domain is primeltd.com, not vanos.gr (the original allow-policy value came from public-source research that predated the rename). This doc, the live Cloudflare Access allow policy, and the Zero Trust org’s login-page footer text (updated via API the same day) all reflect primeltd.com now.
• Login-page branding is also outside version control: the Zero Trust org (tplgr.cloudflareaccess.com) carries its own login_design (header/footer text, logo, colors) via the Access API, separate from the per-app allow policy — a fact discovered the hard way when a footer-text-only PATCH replaced the whole object and briefly cleared the header/logo/colors (immediately restored). Future edits to that config must resend all login_design fields together, not a partial object.