Road Protect Fleet — Architecture & Security Overview


Document	Architecture & Security Overview
Version	1.0
Date	2026-06-23
Classification	Confidential
Owner	Road Protect — Platform Engineering
Intended audience	Partner / external integrator security & architecture reviewers
Status	Approved for NDA distribution

0. Document Control

This document describes the production architecture and security posture of the Road Protect Fleet platform for an external organisation evaluating a partnership or integration. It is written for a technical audience — security reviewers, solution architects, and engineering leads — and is intended to answer the questions a vendor due-diligence or onboarding process typically raises.

What this document is. A faithful, high-level description of how the system is built and protected: where it runs, how clients authenticate, how data and documents are stored, how the database is managed, how secrets are handled, how software is built and shipped, how activity is audited, and how a request flows end-to-end.

What this document is not. It contains no secrets, credentials, private keys, connection strings, or exploitable configuration values. Where a control has a tunable parameter (token lifetimes, cryptographic cost factors, specific managed-rule identifiers, rate-limit thresholds), the document describes the mechanism and its security property rather than the exact value, in line with responsible-disclosure practice for externally shared material.

How to read the diagrams. Diagrams follow the C4 model convention — System Context first, then Containers (deployable units), supported by data-flow and sequence diagrams. Trust boundaries are drawn as dashed groupings. Every diagram is rendered in Mermaid and is reproducible from the source of this document.

1. Executive Summary

Road Protect Fleet is a cloud-native, multi-tenant SaaS platform that helps fleet operators and their partners manage traffic infringements end-to-end: ingesting and normalising fines onto a canonical data model, attributing them to vehicles, drivers and contracts, and driving downstream workflows such as nomination, appeal and payment automation.

The platform runs entirely on Google Cloud Platform (GCP) in the europe-west1 region (EU data residency), on a managed Kubernetes foundation (Google Kubernetes Engine) for the core microservices and on Cloud Run for the web UI. It is delivered through a GitOps continuous-delivery pipeline and operated under a defense-in-depth security model.

Security highlights covered in this document:

Edge protection by a Google Cloud Armor Web Application Firewall (WAF) with OWASP Core Rule Set managed rules, Layer-7 DDoS defense, and per-client rate limiting, fronted by a global Layer-7 load balancer and managed TLS.
Strong authentication: salted, adaptively-hashed passwords; time-boxed, server-revocable session tokens; and two-factor authentication via WebAuthn passkeys and SMS one-time passwords.
Least-privilege authorization with role-based access control and account-scoped tenant isolation.
Encryption everywhere that matters to an external party: TLS 1.2+ for all external traffic and provider-managed AES-256 encryption at rest for the database, object storage, and backups.
Fully managed data services: Cloud SQL for PostgreSQL with regional high availability and automated backups, and Cloud Storage for documents with private, IAM-governed access.
Secret hygiene: no secrets in source code or container images — all secrets are sourced from Google Secret Manager through the External Secrets Operator using Workload Identity.
Auditability: security-relevant actions are recorded to an immutable audit trail and exported to a BigQuery analytics store with PII redaction.

The remainder of the document walks the system top-down (Context → Containers), then through each control domain, and closes with a shared-responsibility matrix and compliance posture.

2. System Overview & Hosting

2.1 What the platform does

Road Protect Fleet is the core platform that manages infringements and fleets. It is complemented by an automation engine — an internal integration service that automates submission and payment workflows and returns their results to the platform asynchronously. The two communicate over authenticated HTTPS using a shared API key (see §5.5).

2.2 Where it runs

Dimension	Detail
Cloud provider	Google Cloud Platform (GCP)
Region	`europe-west1` (EU — single-region residency for primary data)
Core compute	Google Kubernetes Engine (GKE) — managed Kubernetes, private node pools, autoscaling
Web UI	Cloud Run (fully managed, serverless containers)
Primary database	Cloud SQL for PostgreSQL 15 (regional, high-availability)
Object storage	Google Cloud Storage (private buckets)
Analytics store	BigQuery (audit & reporting)

2.3 Public entry points (domains)

The platform exposes its user-facing surface at a single public hostname, TLS-terminated by a Google-managed certificate:

Surface	Domain	Hosting
Web UI	`fleet-v2.roadprotect.co.il`	Cloud Run

The UI is a server-rendered web application that calls the platform API over HTTPS. The API is fronted by the managed edge described in §4 (global load balancer + Cloud Armor WAF), and its CORS policy allowlists the permitted UI origins.

2.4 Environment separation

The platform runs as fully isolated environments — a production environment and a staging environment — on separate Kubernetes clusters, with separate databases, separate secrets, separate edge load balancers, and separate WAF policies. Code is promoted to production only after passing through staging. This separation is enforced structurally by the GitOps delivery model (§10), not by convention.

2.5 Tenancy model

The platform is multi-tenant. Each customer (a Partner, and the Accounts/companies beneath it) is a logical tenant. Tenant isolation is enforced at the application layer: every authenticated request carries the caller's account context, and data-access queries are scoped to that context (see §6). Administrative roles that legitimately cross tenant boundaries are themselves audited (see §11).

[Diagram]

Figure 2.1 — C4 System Context. Who and what interacts with the platform, and where it runs.

3. High-Level Architecture

3.1 Architectural style

The platform follows a containerized microservices architecture orchestrated by Kubernetes. Each service is a single-purpose, independently deployable unit with a well-defined interface; services communicate over the cluster's private network, and only a curated subset is exposed publicly through the edge. State is externalised to managed services (database, object storage, cache), so application containers are stateless and horizontally scalable.

3.2 Container inventory

Container (role)	Responsibility	Exposure
API service	Core REST API and business logic (NestJS)	Public, via WAF
Slow-query API	Isolated pool for heavy/long-running queries and exports	Public, via WAF
Web UI	Server-rendered front end	Public, via Cloud Run
Queue workers	Asynchronous background jobs (queue-driven)	Internal only
Scheduler	Time-based jobs (scheduled exports, maintenance)	Internal only
Messaging gateway	Outbound SMS / one-time-password delivery	Internal only
Document services	Document storage, rendering and OCR	Internal only
Analytics	Self-service reporting (Metabase)	Public, via WAF
Integration/automation engine	Browser-based workflow automation	Internal
Cache & queue backing store	In-cluster cache and job-queue state (Redis)	Internal only

Managed GCP services underpin the containers: Cloud SQL (PostgreSQL) for transactional data, Cloud Storage for documents, BigQuery for audit/analytics, Secret Manager for secrets, and Artifact Registry for container images.

[Diagram]

Figure 3.1 — C4 Container view. Deployable units, their exposure, and the managed services they depend on.

4. Network & Edge Security

All external traffic enters through a single, hardened edge. The platform uses the Kubernetes Gateway API with Google's global external Application Load Balancer, fronted by Google Cloud Armor as the Web Application Firewall.

4.1 Layered edge controls

[Diagram]

Figure 4.1 — Edge request path. Each stage is an independent control.

TLS everywhere at the edge. All public hostnames are served over HTTPS with Google-managed certificates that auto-renew; plain HTTP is permanently redirected to HTTPS. Standard browser security headers (HSTS, anti-clickjacking, no-sniff) are applied.
Web Application Firewall. Cloud Armor enforces the OWASP Core Rule Set managed rules (SQL-injection and cross-site-scripting families among them), tuned to production traffic to minimise false positives while keeping genuine-attack detectors active. The WAF policy is attached to every public backend, not just the API.
DDoS protection. Cloud Armor Adaptive Protection provides automatic Layer-7 volumetric-attack detection and mitigation at Google's network edge.
Rate limiting. The edge applies per-source rate limiting; the application layer adds a second, action-aware rate-limiting tier (see §5.6) — defense in depth against brute-force and abuse.
Managed-rules-as-code. The WAF policy is maintained as version-controlled infrastructure with a documented change/runbook process, so edge security is reviewable and reproducible rather than ad hoc.

4.2 Private networking

GKE runs with private node pools inside a dedicated Virtual Private Cloud (VPC). The database is reached over private VPC networking, not the public internet. Only services explicitly bound to an edge route are publicly reachable; all other services (workers, scheduler, messaging gateway, document/OCR services, cache) are cluster-internal only and have no public address.

4.3 Session affinity & long-lived connections

Real-time features use WebSocket connections; the load balancer applies session affinity so a client's socket pins to a single backend instance for its lifetime, and WebSocket frames bypass payload inspection that would otherwise break the protocol — a deliberate, scoped carve-out rather than a blanket exception.

5. Authentication

Authentication answers "who is calling?" The platform supports three caller classes — interactive human users, administrative/programmatic users, and partner integrations — each with an appropriate mechanism.

5.1 Login flow

Users authenticate with an email/identifier and password over HTTPS. To avoid ever transmitting a plaintext password, the client hashes the password before it leaves the browser; the server then re-hashes that value with a salted, adaptive algorithm before comparison. Failed-attempt account lockout, optional CAPTCHA, and rate limiting protect the login endpoint against credential-stuffing and brute-force attacks.

5.2 Password storage

Property	Approach
In transit	TLS 1.2+, plus a client-side hash so the raw password is never sent
At rest	Salted, adaptively-hashed (bcrypt family) with a per-user salt and an industry-standard cost factor
Rehashing	Stored hashes are transparently upgraded to the current cost factor on successful login
Rotation	Password-age policy with proactive reminders before expiry
Reuse	The current password cannot be re-set to itself
Recovery	Password-reset and forced-change flows use a separate, short-lived, single-purpose token

Plaintext passwords are never stored, never logged, and never recoverable — only verifiable.

5.3 Session tokens (JWT)

Once authenticated, the user receives a signed JSON Web Token (JWT) that represents their session.

Signing. Tokens are signed with a server-held secret (sourced from Secret Manager, §9) and verified on every request.
Transport. The token is accepted either as a Bearer token (Authorization header) or as a hardened cookie — HttpOnly, Secure (HTTPS-only), and SameSite=Strict, which neutralises cross-site request forgery for the cookie path.
Time-boxed. Sessions are valid for a bounded window and then require re-authentication; the lifetime is configurable and treated as a security parameter (value omitted here by policy).
Server-side revocation. Crucially, the platform does not rely on expiry alone. Each user carries a "tokens-valid-from" marker; logout, password change, or an administrative action advances it, instantly invalidating all previously issued tokens for that user. Every request re-validates the token against the live user record — so a stolen token cannot outlive a revocation event.
Minimal claims. Tokens carry identity references only; roles and permissions are resolved from the database per request, never trusted from the token itself.

[Diagram]

Figure 5.1 — Login + 2FA sequence.

5.4 Two-factor authentication (2FA)

The platform provides two strong second factors, both standards-based:

WebAuthn passkeys (FIDO2) — hardware-backed, phishing-resistant public-key credentials. The server stores only the public key and a signature counter (for replay detection); the private key never leaves the user's authenticator. Registration and authentication use the standard WebAuthn ceremonies with short-lived, server-issued challenges.
SMS one-time passwords (OTP) — numeric codes delivered through the internal messaging gateway. Codes are hashed at rest, single-use, short-lived, and subject to send-cooldown and per-hour caps to prevent flooding.

2FA is opt-in per user, with the ability for administrators to require it for specific users or globally. A trusted-device option lets a user skip the second factor on a recognised device for a bounded period; trusted-device tokens are stored only as hashes and are revoked automatically on password change. The 2FA challenge itself is carried by a scoped, short-lived token that cannot be used as a full session token.

5.5 Integration authentication (partner & service-to-service)

Machine-to-machine integration — including the platform↔automation-engine channel and inbound partner webhooks — is authenticated with a static API key presented in the x-api-key header over HTTPS. The key is a shared secret managed exclusively through Secret Manager (never in code or images), validated server-side on every integration request, and scoped to the specific integration endpoints. This is the integration mechanism for external systems working with the platform.

5.6 Application-layer rate limiting

Beyond the edge rate limiter, the API enforces action-aware rate limits (e.g. stricter limits on login, password-reset, and OTP endpoints than on ordinary reads), keyed by authenticated user or source IP, returning standard 429 responses with rate-limit headers. This is a defense-in-depth complement to the WAF.

6. Authorization & RBAC

Where authentication establishes who is calling, authorization decides what they may do.

6.1 Role-based access control

The platform implements role-based access control (RBAC) with database-driven roles and granular permissions, evaluated per request:

Each route declares the permission(s) it requires.
A user's effective permissions are resolved from their roles within the relevant account context — authorization is therefore both role-based and tenant-scoped.
Privileged user classes (administrators/developers) are handled explicitly and separately, and their elevated actions are audited.
A dedicated guard prevents purely-programmatic (API) identities from reaching human-only routes, and partner integrations are constrained to their own route set.

6.2 Tenant isolation

Multi-tenant isolation is enforced in the application's data-access layer: every query is scoped to the caller's account context derived from the validated session, and resource-ownership guards verify that a requested object belongs to the caller's tenant before it is returned or mutated. Cross-tenant access is possible only for explicitly privileged administrative roles, and every such access is recorded in the audit trail.

6.3 Administrative impersonation

Support and administrative workflows may impersonate a user to reproduce an issue. Impersonation is first-class and fully audited: the acting administrator's identity is embedded in the session and carried into every audit record produced during the impersonated session, so the real actor behind every action is always attributable.

[Diagram]

Figure 6.1 — Authorization decision path: authenticate → permission → tenant ownership.

7. Data Storage & Document Security

The platform handles two broad data categories: structured transactional data (in PostgreSQL, §8) and unstructured documents — infringement images, appeal PDFs, identity/licence uploads, payment receipts, and nomination documents — in Google Cloud Storage (GCS).

7.1 Why GCS is secure for this system

Control	How it is applied
Private by default	Document buckets are private — no anonymous or public access.
Uniform bucket-level access	Access is governed purely by IAM (no per-object ACLs), giving one consistent, auditable access model.
Public Access Prevention	Enforced on document buckets, so a misconfiguration cannot accidentally expose objects to the internet.
Encryption at rest	All objects are encrypted at rest with Google-managed AES-256 keys.
Least-privilege identities	Each workload uses a dedicated service-account identity granted only the storage role it needs (e.g. read-only for receipt consumers).
No direct browser access	Buckets are never exposed to browsers directly.

7.2 How documents are served

Documents reach authorised users through two controlled paths, never by exposing a bucket:

Authenticated streaming proxy — the API streams a document to the user only after authenticating and authorising the request, applying safe content-type handling and Content-Disposition/no-sniff headers to prevent content-type confusion.
Short-lived signed URLs — where a document must be handed to a downstream automated process, the platform issues a time-limited, signed URL that grants temporary, scoped access to that single object and then expires.

Object keys are randomised (UUID-based) and sanitised to prevent path-traversal; the receipt-fetch path is locked to a single, explicitly-allowlisted bucket.

7.3 Upload safety

User uploads are validated for type and size (MIME allowlists, size caps) before storage, with an optional antivirus-scanning stage available in the pipeline. Bulk/spreadsheet uploads are processed through validated, idempotent pipelines with per-row error handling.

7.4 Integrity-verified storage

When documents were migrated to GCS, each object was uploaded with server-side checksum validation, then re-read and verified for both checksum and byte-size match against the source before the record was switched over — an integrity guarantee that remains the pattern for document writes.

[Diagram]

Figure 7.1 — Document upload and controlled serving. The bucket is never public.

8. Managed Database & Built-in Safety

The system of record is Cloud SQL for PostgreSQL 15 — a fully managed relational database. Choosing a managed service means a large class of security and reliability controls are provided out of the box by the cloud provider, under a shared-responsibility model (§13).

8.1 What "managed" gives us out of the box

Capability	Benefit
Encryption at rest	All data and backups encrypted with Google-managed AES-256 keys, automatically.
Regional high availability	A synchronous standby in a second zone with automatic failover — no single-zone outage takes the database down.
Automated backups	Scheduled daily backups with multi-day retention, plus transaction-log retention, managed by the platform.
Automatic patching	The provider applies minor-version patches and security fixes during maintenance windows — no unpatched database drift.
Private networking	The database is reached over a private VPC path from the application cluster.
IAM-governed administration	Administrative access is governed by cloud IAM and logged in cloud audit logs.
Monitoring & insights	Built-in metrics, query insights, and alerting integrate with the platform's observability stack.

8.2 How the application uses it

Migration-driven schema. The schema is never mutated by the application at runtime; all changes are applied as versioned, reviewed migrations through the delivery pipeline (§10), each of which must define a reversible down-migration and is tested up and down in CI.
Least-privilege database roles. Distinct roles separate schema ownership, migration (DDL), and runtime read/write privileges, so the running application cannot perform schema-altering operations.
Connection-pool resilience. The API protects the database under load: pool-exhaustion, lock, and statement-timeout conditions are caught and translated into graceful 503 + Retry-After responses rather than cascading failures.

[Diagram]

Figure 8.1 — Managed PostgreSQL: HA topology, private connectivity, role separation, and backups.

9. Secrets Management

The platform's guiding rule is simple: no secret ever lives in source code, in a container image, or in a manifest. All secrets are centralised in Google Secret Manager and delivered to workloads at runtime.

9.1 How secrets flow

[Diagram]

Figure 9.1 — Secret delivery: Secret Manager → External Secrets Operator → Kubernetes Secret → pod.

Single source of truth. Secrets are stored and versioned in Secret Manager.
Pull, don't embed. The External Secrets Operator (ESO) runs in-cluster and reconciles secrets from Secret Manager into Kubernetes Secrets on a schedule, which are then mounted into pods as environment variables at boot.
Workload Identity. ESO authenticates to Secret Manager via GKE Workload Identity — a short-lived, federated identity — so there are no long-lived service-account key files to leak.
Declarative & auditable. Which secret maps to which workload is declared in version-controlled manifests (referencing secret names, never values), so the wiring is reviewable while the values stay private.
Rotation. Because consumers read from Secret Manager, a secret can be rotated centrally; shared integration keys are rotated under a documented procedure.

This model means a leaked manifest, repository, or container image yields no usable secret.

10. CI/CD & GitOps

The platform is built and shipped through an automated, auditable pipeline combining GitHub Actions (continuous integration) and Argo CD (GitOps continuous delivery). The defining property is that the desired state of production is whatever is committed to Git — deployments are reconciliations toward a reviewed, version-controlled state, not imperative pushes.

10.1 Pipeline stages

[Diagram]

Figure 10.1 — CI → image build → GitOps reconciliation → migrate → rollout → verify.

10.2 Key properties

Separation of duties / environment promotion. Staging and production are driven by separate branches and separate clusters; production is deliberately set to manual sync, so a human operator authorises each production reconciliation.
Immutable, traceable artifacts. Every deployment is an immutable image tagged with the exact source commit; the pipeline verifies the live image equals the intended commit after rollout, failing loudly on mismatch.
Database migrations as a gated pre-step. Schema migrations run as a pre-sync job before the new code rolls out, in a transaction-per-migration model, and are tested both forward and backward in CI.
Zero-downtime rollouts. Deployments use rolling updates with health checks, pod-disruption budgets, and graceful draining of in-flight work.
Supply-chain security scanning. Every pull request is gated by automated secret scanning (gitleaks); scheduled jobs run dependency vulnerability auditing, a full-history secret-scan baseline, and dynamic application security testing (OWASP ZAP) against staging. Findings are tracked as issues.
GitOps audit trail. Because all state lives in Git, every change to production — application and infrastructure alike — is a reviewable, attributable commit.

11. Audit Logging & Observability

11.1 Audit trail

Security- and business-sensitive actions are recorded to an immutable audit trail. Auditing is applied deliberately to the endpoints that matter — authentication and 2FA events, user/account changes, bulk uploads, contract/vehicle/infringement/payment/nomination mutations, partner webhooks, and administrative actions — capturing:

Who — the acting user/identity (including the real actor behind any impersonation) and source IP/user-agent.
What — a semantic action name plus the affected resource.
When — a precise, server-stamped timestamp.
Outcome — success or failure, including the error on failure.

Audit records are written on a non-blocking path so auditing never degrades request latency, and personally-identifiable information is redacted from captured payloads before persistence, with the redaction explicitly recorded.

11.2 Export & retention

[Diagram]

Figure 11.1 — Audit data flow: capture → hot store → 5-minute export → analytics store.

The hot tier (PostgreSQL) keeps recent records for fast operational queries; a scheduled job exports new records to BigQuery every few minutes for long-term, queryable retention, after which aged hot-tier rows are pruned. Access to the audit data is itself restricted to authorised administrators.

11.3 Observability

The platform emits structured logs to Cloud Logging (with a sink into BigQuery for analysis), application performance telemetry to an APM tool, and metrics to Cloud Monitoring. Alerting policies are maintained as code and route to the operations team's chat channels — covering edge/WAF blocks, certificate expiry, error-rate and resource thresholds, and queue health.

12. Request Lifecycle (End-to-End)

This section ties the controls together by following a single authenticated API request from the client to the database and back, naming the security checkpoint at each hop.

[Diagram]

Figure 12.1 — End-to-end request lifecycle with security checkpoints and the trust boundary.

Walkthrough.

Edge. The request is TLS-terminated, inspected by the WAF, rate-limited, and screened for L7 DDoS. Only clean traffic proceeds.
Gateway/middleware. Security headers, CORS allowlist enforcement, and request-size limits are applied; a request-scoped identity context is established.
Authentication. The JWT is validated — signature, scope, and revocation against the live user record. Integration requests are instead validated by API key at this stage.
Authorization. RBAC permission checks, tenant-ownership checks, and action-aware rate limits run before any business logic.
Validation. The request body is validated against a strict schema; unknown fields are stripped.
Service & data. Business logic executes within database transactions, using a least-privilege runtime role, with queries scoped to the caller's tenant; documents are read/written through the controlled GCS paths (§7).
Audit & response. Sensitive actions are recorded to the audit trail (PII-redacted, non-blocking); the response is sanitised and returned over HTTPS. Database-overload conditions degrade gracefully to 503 + Retry-After.

13. Shared Responsibility & Compliance Posture

13.1 Shared-responsibility model

Running on a managed cloud means security is a shared responsibility. The matrix below makes the boundary explicit — the single most important thing for a partner to understand.

Layer	Google Cloud (provider)	Road Protect (vendor)	Partner / customer
Physical data centres, hardware	✅
Hypervisor, managed-service internals	✅
Network backbone, DDoS scrubbing	✅	(configures Cloud Armor)
Database engine patching, encryption-at-rest, backups	✅	(configures HA, retention)
OS / container runtime (GKE-managed)	✅ (node OS)	(workloads)
Application code & business logic		✅
Authentication, RBAC, tenant isolation		✅
Data classification & secrets configuration		✅
IAM, network & WAF configuration		✅
End-user / integration credentials		(enforces policy)	✅
Their data & how it is used		(processes per agreement)	✅
2FA enrolment for their users		(provides capability)	✅

13.2 Inherited controls & compliance

By building on GCP, the platform inherits the provider's certified infrastructure controls (Google Cloud maintains SOC 1/2/3, ISO 27001/27017/27018, PCI DSS and other attestations at the infrastructure layer). The platform's own controls — described throughout this document — sit on top of that foundation.

Area	Posture
Data residency	Primary data and backups in the EU (`europe-west1`).
Encryption in transit	TLS 1.2+ for all external traffic; internal traffic on a private VPC.
Encryption at rest	Google-managed AES-256 for database, object storage, and backups.
Vulnerability management	Weekly dependency auditing and DAST against staging; PR-gating secret scanning; container-image vulnerability scanning.
Secrets	Centralised in Secret Manager; no secrets in code/images; federated (key-less) access.
Access control	RBAC, least-privilege roles, account-scoped tenant isolation, audited admin access.
Auditability	Immutable, PII-redacted audit trail with multi-year retention in BigQuery.
Resilience / DR	Regional HA database with automatic failover; automated backups; zero-downtime rolling deploys; isolated staging environment.
Change management	GitOps — every production change is a reviewed, attributable, reversible commit.

13.3 Subprocessors

The platform's primary subprocessor is Google Cloud Platform (hosting, database, storage, analytics, secrets). Outbound SMS delivery uses a telephony provider via the internal messaging gateway. A current subprocessor list and the SOC 2 report of the underlying cloud provider can be made available under NDA on request.

14. Appendix

14.1 Technology stack at a glance

Concern	Technology
Core API	NestJS (Node.js / TypeScript)
Web UI	Server-rendered React (Next.js) on Cloud Run
Database	Cloud SQL for PostgreSQL 15 (regional HA), TypeORM
Object storage	Google Cloud Storage
Analytics / audit store	BigQuery
Cache & job queue	Redis (in-cluster)
Orchestration	Google Kubernetes Engine (GKE)
Serverless UI runtime	Cloud Run
Edge / WAF	Gateway API + global L7 ALB + Cloud Armor
TLS	Google Certificate Manager (managed certs)
Secrets	Secret Manager + External Secrets Operator + Workload Identity
CI	GitHub Actions
CD / GitOps	Argo CD
Container registry	Artifact Registry
2FA	WebAuthn passkeys + SMS OTP
Observability	Cloud Logging, Cloud Monitoring, APM

14.2 Key-entity data model (overview)

A simplified view of the canonical domain model. Column lists are illustrative, not exhaustive.

[Diagram]

Figure 14.1 — Canonical data model (high-level). Tenancy roots at Partner → Account; inbound records enter as Raw Infringements and are mapped onto canonical Infringements.

14.3 Glossary

Term	Meaning
GKE	Google Kubernetes Engine — managed Kubernetes.
Cloud Run	GCP serverless container runtime.
Cloud SQL	GCP managed relational database.
GCS	Google Cloud Storage — object storage.
WAF	Web Application Firewall (Cloud Armor).
OWASP CRS	OWASP Core Rule Set — managed WAF rules.
JWT	JSON Web Token — signed session token.
WebAuthn / passkey	FIDO2 phishing-resistant public-key authentication.
OTP	One-time password.
RBAC	Role-based access control.
GitOps	Git as the source of truth for deployed state (Argo CD).
ESO	External Secrets Operator.
Workload Identity	Key-less federated identity for GKE workloads.
HA / failover	High availability with automatic standby promotion.
DAST	Dynamic Application Security Testing.
PII	Personally Identifiable Information.

14.4 Diagram legend

Solid arrows — request/data flow. Dashed arrows — boot-time or out-of-band relationships.
Cylinders — data stores. Subgraph boxes — trust/deployment boundaries.

14.5 Contact & further information

Detailed evidence — the underlying cloud provider's SOC 2 report, a current subprocessor list, and environment-specific configuration — is available to the partner's security team under NDA through the Road Protect engineering contact.