Appearance
Kubernetes reference architecture
This page describes the Kubernetes deployment the platform is being built toward and what exists today. It is a target architecture for a first customer of roughly 800 to 1,000 users, starting without high availability and with a deliberate path to multi-node HA. It is not a production qualification: the manifests are checked statically and against isolated PostgreSQL, and the whole topology has been run only as a single-node simulation. Read Status before relying on any row.
The endpoint stays the enforcement point. Moving the server to Kubernetes changes where the control plane runs, not where detection happens.
Topology
Workload roles
One binary runs in several modes, so each role gets only the network paths, database privileges and secrets it needs.
| Role | Responsibility | Notable boundary |
|---|---|---|
| Management API | Console and integration routes, enrolment, policy | Cannot update or delete the audit chain; cannot change endpoint events except linking to an incident |
| Ingest | Agent event intake | Requires the gateway-verified device identity on signed routes; one-time enrolment is the only certificate-free exception |
| General worker | Normalise, correlate, retain, deliver | Retention deletions go through bounded database functions, not table-wide DELETE |
| Reports worker | Scheduled reports and analytics | Owns its schedule and delivery tables |
| EDM Matcher | Fingerprints imported datasets and releases keys to agents | Holds the only path to plaintext EDM keys; keys wrapped by the customer KEK |
| Device Issuer | Issues device certificates | Backed by the customer's PKI or HSM |
| Analysis | Fingerprints protected documents an operator uploads | No database, no EDM key, no storage, no egress |
| Discovery worker | Scans mounted shares and remote sources | Opt-in; empty tenant scope by default; read-only source volume |
| Dashboard | Static console | |
| Migration job | Applies schema | The only schema writer; runtime pods wait for their image's migrations |
Data stores
- PostgreSQL holds everything transactional, including the event queue. A dedicated VM or managed PostgreSQL is the leading option for the first customer. The database operating model is an owner decision that is not yet made.
- Object storage is S3-compatible and holds sealed evidence. It is optional and tenant-owned.
- No message broker, no search index. Direct ingestion into PostgreSQL was measured, and the cost is per request, not per event; a broker would defer the same signature, nonce and WAL work and add a component to run. The trigger to revisit is a measured p99 above one second at a rate below the capacity figures.
Security boundaries
| Boundary | Control |
|---|---|
| Agent to cluster | Device-key-signed requests; client mTLS at the agent gateway; the API validates the device URI in the forwarded certificate |
| Between services | Workload mTLS with separate client identities per caller |
| Pod admission | Namespace enforces the Pod Security restricted profile |
| Network | A NetworkPolicy per role; default deny between roles |
| Database | A separate login per runtime service, column-level grants, fail-closed startup checks that refuse unexpected privileges |
| EDM keys | Wrapped by the customer KEK; unwrapped only in the Matcher; the API holds no Vault credential |
| Secrets | A placeholder secret template is not applied by a directory apply |
| Tenants | tenant_id in every lookup and composite foreign keys in the schema |
Sizing
The measured single-host figures are in Capacity: 3,385 events/s ingestion-only and 2,622 events/s with every event matching a policy, as floors. PostgreSQL write-ahead-log storage dominates; on Kubernetes put pg_wal on local NVMe rather than network-attached storage, and keep agent batches at the default of 100 events.
Status
| Item | State |
|---|---|
| Split roles, per-role NetworkPolicies, Pod Security labels | Implemented in manifests; static checks pass |
| Per-service database roles and grants | Implemented; tested against isolated PostgreSQL 16 |
| Analysis service and EDM Matcher as separate workloads | Implemented in source; images not yet built and deployed in a cluster |
| Agent gateway mTLS contract | A template exists; it depends on the customer's PKI and gateway CRDs |
| NetworkPolicy enforcement | Not yet proven on a live CNI |
| Wrapped EDM keys for existing datasets | A dry-run-first rewrap tool exists; existing keys have not been rewrapped against a customer database |
| Management API privilege minimisation | Incomplete: it still holds broad grants on some application tables |
| High availability | Not built. First deployment is single-replica for PostgreSQL |
| Production topology | Not qualified. A single-node cluster on one VM is a service simulation, not a capacity or security qualification |
Operational steps for the manifests that exist are in Server deployment.