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 required 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, or a passkey, held in your Postgres. No external identity provider at this release |
Outbound: the relay, plus optional dashboard calls
The dashboard can also check for new versions and send email. All of it is optional and carries no agent data. See Data handling.
The relay has one destination and 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 required 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 |