Architecture and data flows

Written for a security reviewer. Everything here is observable in a running install, and every claim has a page you can check it against.

What runs where

Two namespaces, three charts, one ingress point.

                        internet
                            │
                            │  api.gen0sec.com:443  (the only outbound path)
                            │
┌───────────────────────────┼──────────────────────────────────────────────┐
│ your cluster              │                                              │
│                           ▲                                              │
│  ┌─────────────────────── │ ─────────────────────────────────────────┐   │
│  │ namespace: gen0sec     │                                          │   │
│  │                        │                                          │   │
│  │   dashboard      relay(download-api)      13 application services │   │
│  │                                                                   │   │
│  └───────────────────────────────┬───────────────────────────────────┘   │
│                                  │  in-cluster only                      │
│  ┌───────────────────────────────┼───────────────────────────────────┐   │
│  │ namespace: gen0sec-system     │                                   │   │
│  │                               ▼                                   │   │
│  │   Postgres (3)   Kafka (3)   object store (4)   caches (2)        │   │
│  │   Postgres operator   Kafka operator   ingress operator           │   │
│  └───────────────────────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────────────────────┘
                            ▲
                            │  one address, TLS, path-prefix routed
                            │
                     your agents and your users

Namespace	Contains	Reachable from outside
`gen0sec`	The application services and the dashboard	Yes, through the ingress you publish
`gen0sec-system`	Postgres, Kafka, object store, two caches, and the three operators	No

Nothing in gen0sec-system is published. The application reaches it by cluster DNS.

Trust boundaries

Four, and they are worth naming separately because they fail differently.

Boundary	Crossed by	Controlled by
Internet to cluster	The relay, outbound only, one destination	Your firewall. See Ports and egress
Your network to cluster	Agents and users, inbound, one address	Your ingress and its TLS
Namespace to namespace	The application reading its databases	Cluster DNS. No NetworkPolicy ships. See Hardening
Cluster to registry	Image pulls	The image pull secret, one per namespace

Data flows

Inbound: agents and users

Flow	Path	Authentication
Agent telemetry and events	Your address, then the ingest services, then Kafka, then Postgres	Agent API key
Agent configuration pull and push	Your address, then the configuration services	Agent API key
Agent artifact download	Your address, then the relay, then Gen0Sec	Agent API key, validated locally. The relay uses your installation's own key upstream, so agent keys never leave. See Data handling
Dashboard sign-in	Your address, then the dashboard, then Postgres	Email and password, held in your Postgres. No external identity provider at this release

Outbound: the relay, and nothing else

One destination, one purpose: fetching four licensed datasets that are in no artifact we ship.

Dataset	Why it cannot be shipped
CTI indicators	Licensed by upstream providers
GeoIP databases	Licensed by MaxMind and IPInfo
ML models	Published by gen0sec, refreshed independently of releases
IDS rules	Licensed as part of the Emerging Threats ruleset

The relay is a relay, not a cache. Nothing is stored on the way through, so there is no local artifact store to size and no staleness window.

Never outbound

Dataset	What it is	Where it stays
`identity`	Workload identity produced in your cluster	Your object store
`policy-edges`	Pod IPs, namespaces, NetworkPolicy edges	Your object store

Relaying either would push a map of your workload topology to a service you do not run. It is not configurable and there is no flag that enables it. Uploads are not relayed either: the relay is read-only.

Where data is stored

Store	Contains	Backed up by you
Postgres	The system of record: configuration, agents, policy, history	Yes, always
Object store	Datasets, and the two locally-produced sets above	Yes
Kafka	In-flight events between ingest and persistence	No, it is transport
Cache	Nothing durable	No

See Back up and restore.

What the platform requires of your cluster

Requirement	Detail
`cluster-admin` during install	For CRDs and cluster-scoped RBAC. See Privileges and RBAC
Custom resource definitions	Postgres and Kafka operator CRDs, cluster-scoped by nature
Its own ingress controller	Installed by the infra chart, `ingressClassName: synapse`
One outbound destination	`api.gen0sec.com:443`
No node access, no host mounts, no privileged containers	See Hardening

Questions a reviewer usually asks next

Question	Page
What exactly can leave the cluster?	Data handling
What ports and destinations do I open?	Ports and egress
Why does it need `cluster-admin`?	Privileges and RBAC
How do I verify what you shipped me?	Supply chain
What is the container security posture?	Hardening
What does not work yet?	Known limitations

What runs where​

Trust boundaries​

Data flows​

Inbound: agents and users​

Outbound: the relay, and nothing else​

Never outbound​

Where data is stored​

What the platform requires of your cluster​

Questions a reviewer usually asks next​