Requirements

Cluster

	Requirement
Kubernetes	1.23 or later
Access	cluster-admin, for the install only. See Privileges and RBAC for what it is used for and what it leaves behind
StorageClass	A default StorageClass on block storage. Volume expansion recommended
Supported architecture	linux/amd64 or linux/arm64. Mixed-architecture clusters are supported
LoadBalancer	The ingress data plane is exposed as a LoadBalancer type Service by default. See the note below

The ingress needs to be reachable from outside the cluster

The ingress data plane is a LoadBalancer type Service, because nothing it programs can serve traffic if it stays cluster-internal. Your cluster needs a LoadBalancer implementation.

If your cluster fronts ingress another way, a NodePort, a hardware balancer or an external proxy, change the Service type to match.

Cerebellum brings its own data plane - which contains Postgres, Kafka, object store and cache. You do not connect it to existing instances of any of them.

Maintenance

We've deliberately chosen to use well-known solutions from the software industry in our data layer to ease the burden of maintenance. While Cerebellum ships this data layer by default, to make the setup easier, the data in it is the highest importance to you. So make sure you monitor the dataplane and do backups and maintenances regularly.

Container runtime, for the registry install method only

Our registry challenges pulls that carry no User-Agent, and on some distributions the kubelet's pull path sends none. containerd's own user agent passes; the problem is its absence. Either configure one on every node, or use the offline bundle method, which pulls into your own registry instead.

Settle this before you choose a method. See Known limitations.

Kubernetes versions

1.23 is the floor because autoscaling/v2 is the newest API the charts use, and it reached GA in that release. While anything from 1.23 and up should work, we recommend you use the latest stable version.

Sizing a production install

Production runs on 3 nodes. Several data plane members each form a three-member quorum, so three is the floor for redundancy, not a suggestion.

CPU & memory per node

	Resources
Minimum	8 vCPU, 16 GiB
Recommended	16 vCPU, 32 GiB

Storage per node

We recommend to start your nodes with 500 GiB minimum.

Several of the data plane members use PVCs. While the defaults are kept low - as your platform matures the data will grow and you'll need to expand the storage volumes.

Sizing storage for your retention

The shipped sizes are a starting point, not a capacity plan. They are deliberately modest, so for most production workloads you will be growing them rather than shrinking them.

Four keys control everything:

Key	Chart	Default
postgres.volume.size	gen0sec-data	50 GiB
kafka.storage.size	gen0sec-data	50 GiB
rustfs.storageclass.dataStorageSize	gen0sec-infra	50 GiB
rustfs.storageclass.logStorageSize	gen0sec-infra	10 GiB

Which one to grow depends on what you are retaining:

If you need	Grow
Longer event and telemetry history	postgres.volume.size. This is the system of record
A longer Kafka retention window, or a bigger ingest buffer	kafka.storage.size
More room for datasets and locally-produced artifacts	rustfs.storageclass.dataStorageSize

Example for longer retention:

# gen0sec-data
postgres:
  volume:
    size: 200Gi
kafka:
  storage:
    size: 200Gi

# gen0sec-infra
rustfs:
  storageclass:
    dataStorageSize: 100Gi

Plan for growth

Volume expansion grows a volume if your StorageClass supports it, and it is straightforward. Nothing shrinks one: reducing a size means recreating the volumes and losing what is on them.

Starting at the shipped defaults and growing is therefore the recommended direction. It is the reason for low initial limits.

Check that your StorageClass has allowVolumeExpansion: true before you install.

What is not on this page

Throughput. How many agents, events per second or lookups a given topology sustains is not directly derivable from the charts' parameters. We suggest you scale the platform components and storage sizes according to your topology's specific needs.

Evaluating on one node

Use the Quickstart. It runs everything at a single replica on one node, for evaluation, training and upgrade rehearsals.

Tools on your workstation

Install these on the machine you run the commands from, not on the cluster.

Tool	Version	Used for	Install
helm	3.16 or later	Installing the charts, and pulling them from the registry	helm.sh
kubectl	matching your cluster	Everything cluster-side	kubernetes.io
cosign	2 or later	Verifying signatures on the install kit, images and charts	docs.sigstore.dev
skopeo	any	Copying images between registries	github.com/containers/skopeo
yq	4 or later, mikefarah/yq only	Reading the release manifest	github.com/mikefarah/yq
jq	any	Reading the release API	jqlang.github.io
aws or mc	any	Creating the object store bucket, one step during install	aws-cli or MinIO client
curl, tar, openssl, sha256sum or shasum	any	Downloading, unpacking, generating secrets, checking checksums	Your OS packages

Check your yq

There are two separate tools that are called yq. The Python one (kislyuk/yq) cannot parse the expressions the bundler uses, and it fails with a syntax error partway through.

yq --version

The output must contain mikefarah. If it does not, install the Go version and point the bundler at it:

export MIKEFARAH_YQ_PATH=/path/to/mikefarah-yq

Credentials from Gen0Sec

You need two, and they are different things. Missing the second one produces a working-looking install whose entire fleet silently receives nothing.

Credential	Used by	Used for
Registry token	The bundler and registry based installs	Downloading the install kit, pulling charts and images
Your Gen0Sec API key	The relay pod, inside your cluster	Fetching threat intelligence, GeoIP, models and IDS rules from Gen0Sec

The registry token

The registry token is provided by Gen0Sec support, while you can obtain the API key from the SaaS Dashboard. The username is literally any. Wherever a command asks for one, type any. Only the token is checked.

Your Gen0Sec API key

You can create your API key on the SaaS Dashboard

Scopes required:

• ids_rules:read,
• indicators:read,
• ml_models:read

Why this one is separate from the registry token

Your agents get their API keys from your own dashboard, and those keys exist only in your cluster's database, so they cannot authenticate to Gen0Sec. The API key created in this step is used by your in-cluster relay to authenticate against the Gen0Sec SaaS, so it can fetch data related to threat intelligence, GeoIP, ML models and IDS rules.

The chart expects it as a secret named gen0sec-download-proxy, and the relay pod will not start without it, so a missing key is a failed rollout rather than a silently degraded fleet. You will create this secret in the step 2 of Install.