Skip to content

Network Architecture

Statement

ClaimGuard's production network architecture today is a single VM on the GCP default VPC in europe-west1-b with two parallel public HTTPS ingresses terminating at the same backend:

  • https://claim-guard.dtectvision.ai — nginx on the VM with a Let's Encrypt cert. This is the canonical user-facing URL today. Nginx serves the static frontend assets and reverse-proxies the API path to the application backend over loopback.
  • https://app.dtectvision.ai — GCP global external HTTPS Load Balancer with a Google-managed cert (ACTIVE since 2026-05-03), Cloud Armor security policy attached (per-IP rate limit + Adaptive L7-DDoS protection, since 2026-05-04), and an HTTP→HTTPS 301 redirect on the same IP. This path is the API-only ingress.

The future canonical user URL is app.claim-guard.ai once that domain is provisioned. There is no separate DMZ or backend tier — the application, the internal analysis services, and the database all live on the same host and communicate over 127.0.0.1.

A small residual 0.0.0.0/0 ingress remains on a narrow set of internal tool ports on the VM IP (narrowed during the firewall- narrowing step but not yet fully closed). The application calls these ports only over loopback; nothing external connects to them. Tightening this is on the roadmap and does not affect the user- facing TLS posture.

Implementation

Topology today

The full topology is illustrated in the architecture diagram bundled with this trust portal (see Cloud provider for the service-level breakdown). At a glance:

  • Public ingress (canonical user URL): browser → nginx + Let's Encrypt → application backend over loopback.
  • Public ingress (API): API caller → GCP HTTPS Load Balancer + Cloud Armor → application backend.
  • Single VM in europe-west1-b, hosting nginx, the application backend, the internal analysis services, and the application database. All cross-process communication is loopback-only.
  • GCP control plane (Secret Manager, Cloud Logging, Cloud Storage, IAP) reached over TLS from the VM.
  • Outbound to the internal analysis services over TLS for the internal analysis component.

Topology specifics

  • One VPC: GCP default (auto-mode). The VM lives in europe-west1-b.
  • One VM with an encrypted boot disk and Shielded VM Secure Boot enabled.
  • One public IP on the VM (a static external IP).
  • One database on the VM's boot disk (Postgres). No Cloud SQL.
  • No subnets beyond VPC defaults. No separate "frontend" / "backend" / "data" tiers.

Trust boundaries

  • Public → nginx → VM (loopback) is the canonical user path: browser → claim-guard.dtectvision.ai over TLS → nginx terminates TLS with a Let's Encrypt cert → nginx serves the static frontend and reverse-proxies the API path to the application backend on loopback.
  • Public → LB → VM (LB-internal hop) is the parallel API ingress: caller → app.dtectvision.ai over TLS → HTTPS LB terminates TLS with Google-managed cert → Cloud Armor evaluates → backend NEG → VM.
  • The VM's direct public IP is still reachable on a small set of internal tool ports via the internal-tool firewall rule. The world-open dev-server and direct backend rules were closed during the firewall-narrowing step (2026-05-04).
  • VM ↔ GCP control plane (Secret Manager, Cloud Logging, GCS) is TLS to Google-issued certificates, validated against the system trust store.
  • Inside the VM: application backend, analysis services, and database all communicate over loopback (127.0.0.1). Documented as a deliberate design choice in the internal architecture-protocol document so cross-process calls don't need a VPC firewall rule.

Outbound paths

  • GCP services as above.
  • External internal analysis API from an internal analysis service over TLS. See AI transparency.
  • Customer-supplied webhooks wrapped by the outbound-HTTP wrapper, which enforces TLS for https:// URLs, blocks private / link-local / CGNAT ranges, and refuses redirects by default. See SAST for the full invariant set.

Firewall posture

The current VPC firewall rules are documented and being narrowed in phases (the firewall-cleanup steps):

  • Done — the default RDP firewall rule deleted; nothing legitimate used it.
  • Done — duplicated world-open SSH rules deleted; SSH is now IAP-only on Google's IAP source range.
  • In progress (2026-05-04) — close the remaining dev / internal ports world-open today now that the LB serves the production path:
  • The dev-server firewall rule: deleted 2026-05-04.
  • The internal-tool firewall rule: direct backend port removed 2026-05-04; rule still allows internal FastAPI tool ports that nothing external should reach. Narrowing further is the remaining firewall-narrowing residue task.
  • An internal-tools firewall rule for additional ports: still in place, deferred pending operator confirmation that no external client uses these ports.

See Network security for the firewall record and rationale.

Why no separation today

A multi-tier network with a frontend load balancer, a private backend subnet, and Cloud SQL for the database is the textbook target shape. We are not there yet because:

  • Pre-launch, the additional GCP cost would be unjustified.
  • Internal traffic over loopback removes a category of cross-VM network bugs and a category of inter-tier authentication code.
  • The architecture is documented honestly so the trust portal does not over-claim what the topology delivers.

The cost of getting there incrementally is small, and the plan sequences it: the LB rollout step (HTTPS LB) is in production; the Cloud SQL migration step (longer-term) moves Postgres to Cloud SQL.

Status

implemented — verified 2026-05-06. Two parallel public HTTPS ingresses live (nginx + Let's Encrypt at claim-guard.dtectvision.ai canonical user URL; GCP HTTPS LB at app.dtectvision.ai API ingress, with Cloud Armor). HTTP→HTTPS redirect on both. IAP-only SSH. Loopback-only internal traffic. Known gaps below are roadmap items.

What's in place:

  • A documented, reproducible single-VM topology with two parallel public HTTPS ingresses.
  • HTTP→HTTPS 301 redirect on both ingresses.
  • IAP-only SSH (no public SSH path).
  • TLS for every outbound path (GCP control plane, operator webhooks via the outbound-HTTP wrapper).
  • Loopback-only internal traffic for analysis services — no inter-VM network hop required for the on-VM stack.
  • An immutable cloud audit log of every network configuration change.

Known gaps

  • Internal tool ports still world-open via the internal-tool firewall rule (the application calls these only over loopback; nothing external should reach them). Tracked as the residual firewall-narrowing task.
  • No multi-tier separation (frontend / backend / data). Single VM hosts everything.
  • Database on the VM (cross-listed on Cloud provider and Backups). VM compromise = full DB compromise until the Cloud SQL migration step.
  • Single zone (europe-west1-b). Zonal outage is a service interruption.
  • Cross-VM plain HTTP hop: the image-analysis service makes outbound calls to an internal peer VM over plain HTTP. Should move to TLS or a VPC-private network hop.
  • Several legacy world-open firewall rules still exist on the VPC for sibling workloads (see Network security). The firewall-narrowing step closes them; dev-server rule deleted 2026-05-04, internal-tool rule narrowed 2026-05-04.

Roadmap

  • Firewall-narrowing residue — close the remaining internal ports on the internal-tool firewall rule; possibly delete the internal-tools firewall rule entirely.
  • Cloud SQL migration — Postgres → Cloud SQL with point-in-time recovery, which also removes the database from the VM trust boundary.
  • Future canonical URL — cut over to app.claim-guard.ai once the new domain is provisioned (DNS + cert).
  • Multi-zone or multi-region availability — not on the immediate roadmap; revisit after Cloud SQL migration.