Skip to main content
Security

Security built in, not bolted on

Authentication, authorization and encryption are part of the store — one trust fabric across the data plane and the console, configurable per store, with no extra services to run.

AuthenticationAuthorizationTLS & CA models
Defense in depth

Three layers, one fabric

One built-in trust fabric secures node-to-node traffic, client connections, and the management plane — the same identity and authorization model across the whole cluster.

Authentication

Offline-verified bearer tokens — the node checks the signature against a cached cluster key, with no auth-server round trip on the hot path.

Authorization

Deny-by-default RBAC — subjects get roles, roles grant permissions on stores and admin operations. Nothing is allowed unless it is granted.

Encryption

Mutual TLS between nodes and server-auth TLS for clients, across four CA/trust models — turn it on per store.

Authentication

Tokens, verified offline

Clients present a bearer token; the node verifies its signature against the cluster's cached public key — no call to an auth server on the request path. Keep the token out of the connection string with env: or file: references.

  • No auth-server dependency on the hot path
  • Tokens minted by the manager; scoped and expiring
  • Safe indirection — secrets never sit in the URL
zariss://n0:7861/store?token=env:ZARIS_TOKEN
Clientpresents bearer token?token=env:VAR / file:/pathtokenZaris nodeverifies signature offlineverifier · cached cluster public keyno round trip to an auth serverallow / denyManagerissues tokens
Subjectuser · service · tokenRolesreader · writer · adminassigned per subjectPermissionson stores & admin opsread · write · manageeverything else: denied by default
Authorization

Deny-by-default RBAC

Access is granted, never assumed. Subjects are assigned roles; roles map to permissions on stores and admin operations. Anything not explicitly granted is denied.

  • Reader / writer / admin roles, or your own
  • Enforced at the node — not just in the UI
  • Least-privilege by construction
Encryption

Mutual TLS across the cluster

Node-to-node gossip and replication run mutual TLS; the client data plane is server-auth, where the client verifies the node and authenticates with a token. On Kubernetes the node leaf can carry a multi-SAN certificate so external clients validate too.

  • Mutual TLS node ↔ node; server-auth for clients
  • Automatic leaf renewal before expiry
  • Turn it on per store — plaintext stays the default for dev
zaris-0presents + verifies certzaris-1presents + verifies certmutual TLS · node ↔ nodeClientverifies node · sends tokenserver-auth + token
Trust, your way

Four CA / trust models

From zero-PKI auto-issuance to mounting certificates your own CA issued — pick the trust model that matches your organization.

M0 · Auto / co-located

The manager mints a cluster CA and issues node leaves automatically. Zero PKI to run — great for getting secure fast.

M1 · Bring-your-own CA

Provide your own root CA; the cluster issues leaves from it, so Zaris chains to trust you already operate.

M2 · Intermediate CA

Issue from an intermediate under your corporate root; leaves present the full chain to the anchoring root.

M3 · Pre-issued leaves

Mount externally-issued leaves + CA as secrets (e.g. cert-manager). Zaris just loads and serves them.

Read the security docs →
In the console

Configure and audit it in one place

Initialize the cluster CA, mint enrollment tokens, pick the trust model, and see TLS status per node — all from the built-in Security & TLS view.

console · security & tls
Clustron Zaris console — Security & TLS management

Secure by configuration, not by project

Turn on tokens, RBAC and TLS per store — no bespoke security service to build, run, and keep patched.

Security overviewSee the architecture