Skip to content
Spinoza

Security posture

Two modes, two trust boundaries.

Spinoza runs locally with your kubeconfigs, or inside one cluster for a team. Each mode has its own trust boundary.

  1. Local mode stays local. It refuses a non-loopback bind, rejects non-local Host and Origin, and exits when the last client disconnects.

  2. Authentication is explicit. Local mode uses a token minted for that run. Cluster mode uses your OIDC provider or an authenticated proxy; anonymous administration needs an explicit unsafe opt-in.

  3. The shared default reads, and nothing more. The Helm chart runs Spinoza from a read-only service account with no access to Secrets and no right to impersonate anyone.

  4. Kubernetes can make the final call. Turn on impersonation for named users and groups, and Spinoza acts as the signed-in account. Tables and search then show only the namespaces that account may list, and the apiserver judges every write.

  5. Kubeconfigs stay in place. Local mode references them where they are, re-reads them and never merges them into a managed file.

  6. Release provenance is published. Archives, desktop apps, the container image, Helm chart and SBOMs carry build provenance. The installer verifies checksums before it writes anything.

  7. Changes are on the record. Every change Spinoza makes is kept with who asked for it and whether the cluster allowed it. In cluster mode sign-ins join the trail, admins export it, and terminal transcripts are kept only when a deployment turns them on.