Known limitations
If you hit something that is not on this page, we'd like to hear about it!
No zero-egress deployment
What it means. Your cluster must reach api.gen0sec.com on port 443. That connection carries
threat intelligence, GeoIP, ML models and IDS rules, which are licensed upstream data that is in no
artifact we ship.
What you can remove. All dependency on Gen0Sec-hosted registries. The offline bundle method mirrors every image and chart into your own registry, so your cluster pulls nothing from us.
What you cannot remove. The runtime connection. There is no supported configuration with zero cluster egress.
If your policy forbids all egress, please contact us.
Our registry challenges pulls that send no user agent
By design on our side, and it can decide which install method you use.
Symptom. Every image pull from registry.gen0sec.com returns 403 with a CAPTCHA challenge, and
pods sit in ImagePullBackOff. A manual docker pull or skopeo copy from the same node succeeds.
That discrepancy is the whole diagnosis. If the CLI works and the kubelet does not, this is it.
Cause. On some Kubernetes distributions, the component that services the kubelet's pull sets no
User-Agent header. Go's net/http then sends its own default, Go-http-client/1.1, and our edge
treats that as a scanner signature and issues a challenge. A kubelet cannot solve a CAPTCHA, so the
pull never succeeds and never will.
It is not your credentials, not the pull secret, not TLS, and not an allowlist.
What passes and what does not
Measured against our registry:
| User-Agent | Result |
|---|---|
containerd/1.7.0 | 200 |
containerd/v2.1.4 | 200 |
docker/29.4.0 | 200 |
curl/8.7.1 | 200 |
skopeo/1.24.0 | 200 |
Go-http-client/1.1 | 403, challenged |
Go-http-client/2.0 | 403, challenged |
containerd's own user agent is fine. Any real one is. The failure is specifically the absence of a
user agent, which Go turns into Go-http-client.
Confirming it
The blocked response identifies what it matched:
"user_agent": "Go-http-client/1.1", "ja4_fingerprint": null, "captcha_validated": false
Compare a manual pull against what the kubelet gets:
# on the node: succeeds, because the CLI sends its own user agent
skopeo inspect docker://registry.gen0sec.com/gen0sec/auth-api:0.1.0
# what the kubelet sees
kubectl -n gen0sec describe pod <pod> | grep -A3 Failed
Success from the CLI plus 403 from the kubelet confirms it.
Two ways forward
Option 1: use the offline bundle method. Nothing to configure on your nodes, and your own registry does not inspect user agents. See Prepare the artifacts.
Option 2: make the pull path send a user agent, on every node.
If you cannot change container runtime configuration on your nodes, whether by policy or because your distribution manages it, use the offline bundle method. This constraint forces that choice, and it is better made before you start than at the first failed pull.
The relay cannot use an explicit egress proxy
Symptom. You set HTTPS_PROXY on the relay. Nothing changes, and nothing errors.
Cause. Every HTTP client in the platform builds its own transport without proxy support, so
HTTP_PROXY and HTTPS_PROXY are ignored inside the cluster. This is by design.
What works instead.
| Option | Notes |
|---|---|
Allow api.gen0sec.com:443 directly | One firewall exception that bypasses the proxy |
| Redirect transparently at the network layer | The client does not need to be proxy-aware |
A TLS-intercepting proxy also cannot work: the charts expose no way to mount a CA bundle into the platform containers, and the relay rejects the intercepted certificate.
The object store bucket is not created for you
Symptom. Services start and then fail to read or write the object store. download-api answers
500 NoSuchBucket.
Cause. Nothing in the charts creates the bucket.
What to do. Install step 5 creates it. It is a first-class step, not an optional one.
Five services report readiness from a weaker probe
download-api, ids-rules-api and service-graph-api serve a richer /status/healthz and, in doing
so, never register /status/readyz. Requesting it returns 404, so a readiness probe pointed at it
fails forever while liveness stays healthy, and the pod sits at 0/1 with zero restarts.
What that means for you. Do not repoint those services at /status/readyz. It will fail.
Helm never upgrades CRDs
Not our defect, but it will bite you on the first upgrade that contains CRDs, so it is here.
Helm installs a chart's CRDs on first install and ignores them from then on. An upgrade that ships a new CRD schema fails with a server-side-apply error, or silently rejects new fields.
Upgrade applies them by hand as step 1. Do not skip it.
Kafka volumes survive an uninstall
deleteClaim: false is deliberate, so helm uninstall leaves the Kafka volumes behind. Reinstalling
against them produces Invalid cluster.id ... Expected X, but read Y, because the new cluster
generates a new identity.
Delete the volume claims first, or restore the original cluster. See Kafka will not start.
Migration force means the opposite of what people expect
migrate force <version> marks that version applied and continues with the next one. To re-run a
migration that failed, force the version before it.
Migrations are not idempotent. Forcing to the wrong version re-runs DDL that already exists and fails
with already exists.