Network and connectivity
Why the platform must reach Gen0Sec
No platform is useful without data, neither is Gen0Sec. Because the datasets are licensed per customer,
they are not in the install kit, not in the offline bundle, and not in any container image. The platform
fetches them at runtime from api.gen0sec.com.
| Dataset | Licensed by |
|---|---|
| CTI indicators | Upstream threat intelligence providers |
| GeoIP databases | MaxMind, IPInfo |
| IDS rules | Emerging Threats ruleset |
| ML models | Trained and published by Gen0Sec |
One in-cluster service, download-api, does the fetching. It relays each request upstream and
streams the response straight back. It is a relay, not a cache, so there is no artifact bucket to
size, no sync job to supervise and no staleness window. An agent that polls gets whatever upstream
has at that moment. This also means you get the most recent data we can provide.
One hop, not many
Your agents never talk to the internet. They talk to download-api, and download-api is the only
service in either namespace with a route out.
agents -> download-api -> api.gen0sec.com:443
^
|
the only egress point in the deployment
That means one destination to allow, one to audit. It also means the relayed URLs are identical to the direct ones, so agents need no configuration change.
What never leaves your cluster
Two datasets describe your own infrastructure, and they are never relayed:
| Dataset | What it contains | Where it stays |
|---|---|---|
identity | Workload identity produced in your cluster | Your object store |
policy-edges | Pod IPs, namespaces, NetworkPolicy edges | Your object store |
No hidden switches, no configuration options, it is not implemented. Your data is yours and yours only.
Uploads are not relayed either. The relay is read-only, so PUT and POST on the download surface
are served locally or not at all.
How authorization works
Your agents' API keys never leave your cluster.
Agents authenticate to your installation with keys your own dashboard issued, held in your own database. On a correct configuration the relay does not forward those keys upstream. It presents your own Gen0Sec API key, the one issued with your subscription, on the second hop only.
agent --[your agent's key]--> relay --[your Gen0Sec API key]--> api.gen0sec.com
agent key stops here
| What Gen0Sec sees | One credential, belonging to your installation |
| What Gen0Sec never sees | Any individual agent key, or how many you have issued |
| Revoking an agent | Entirely local, in your dashboard |
| Revoking your installation's access | Revoke or rotate your Gen0Sec API key |
With no Gen0Sec API key configured, the relay falls back to forwarding the caller's own key. That is correct for the hosted product, where the same platform issued it. Here it is always wrong: your keys exist only in your cluster, so Gen0Sec rejects every one with a 401, and the agent reports an empty ruleset rather than an error.
The install may look healthy, but the fleet quietly stops receiving threat intelligence, GeoIP, models and IDS rules.
Set up in Install step 2, enabled in step 7, and checked by Verify the install.
Routes that are not relayed, including identity and policy-edges, keep the local authorization
check against your own database.
Egress list
All connections are outbound, TCP, TLS. Nothing needs an inbound rule from the internet.
| Destination | Port | Needed by | Purpose | Required |
|---|---|---|---|---|
api.gen0sec.com | 443 | Cluster pods (download-api only) | Threat intelligence, GeoIP, ML models, IDS rules | Always |
releases.gen0sec.com | 443 | Your workstation | Download the install kit and its signature | Always |
registry.gen0sec.com | 443 | Your workstation | helm pull for charts, skopeo copy for images | Always |
registry.gen0sec.com | 443 | Cluster nodes (kubelet) | Image pulls at install time | Registry install only |
fulcio.sigstore.dev | 443 | Your workstation | cosign certificate verification | Always |
rekor.sigstore.dev | 443 | Your workstation | cosign transparency log verification | Always |
tuf-repo-cdn.sigstore.dev | 443 | Your workstation | cosign trust root refresh | Always |
| Your own registry | 443 or 80 | Cluster nodes, and the host that runs bundler.sh apply | Image pulls at install time | Offline bundle only |
cosign verify-blob checks a signature against a public transparency log. Without those three
destinations it fails, and it fails on the first command of the install. Allow them on the
workstation, not on the cluster.
Inside the cluster
No NetworkPolicy is required for the install. If you enforce a default-deny policy, the two
namespaces need to reach each other: the application in gen0sec talks to Postgres, Kafka, the
object store and the cache in gen0sec-system.
What this rules out
api.gen0sec.com on port 443 is required for the platform to serve data. An agent fleet with the platform hosted on
a cluster that is permitted no outbound connections at all cannot function correctly.
The offline bundle method removes every dependency on gen0sec-hosted registries: your cluster pulls images only from your own. It does not remove the runtime connection, because the mentioned datasets above are not ours to ship.
If your policy allows no cluster egress, talk to us. We would rather hear it now than during your evaluation.
Air-gapped. Often used to mean "no connection of any kind". Under that definition Cerebellum is not deployable. If it means "no dependency on vendor-hosted registries and one audited outbound destination", the offline bundle method fits, and this page is the list your firewall team needs.