Secure a store end to end
This is the happy path: take a plaintext supervisor-model cluster and lock it down completely, then connect an application. Every step shows both paths — the web console and the AdminShell cmdlet — because they do the same thing through the same management API. Pick whichever you prefer; you can mix them freely.
Keep the two-plane model in mind throughout:
- Control plane (console + admin cmdlets) → secured with credentials (a username and password).
- Data plane (your app ↔ a store) → secured with a token (passwordless, per store).
Turning on cluster security secures only the control plane. Each store's data plane stays open until you enable it on that store (step 3). And TLS alone is encryption without authentication — a TLS-only store is encrypted but still open. Do steps 3 and 4 for every store that holds real data.
Step 1 — Turn on cluster security
This bootstraps the shared signing key and switches on enforcement for the control plane.
Console — Security & TLS → Overview → Enable enforcement. The card flips to Enforced, issuer clustron://zaris.
PowerShell
Initialize-ZrSecurity -AdminSubject admin -AdminPassword (Read-Host -AsSecureString)
Get-ZrSecurityStatus # Enabled: True, Initialized: True
-AdminPassword makes the first admin a real login user you can sign in with. (Already bootstrapped? Toggle enforcement at runtime with Enable-ZrSecurity / Disable-ZrSecurity.)
Step 2 — Create an operator login (a credential)
A credential is a person. This is the identity you and other operators use to sign into the console and run admin commands.
Console — Security & TLS → People → New user: username, password, and a role (for example ClusterAdmin).
PowerShell
New-ZrUser -Name demoadmin -Password (Read-Host -AsSecureString) -Role ClusterAdmin
From now on the console shows a Sign in page to any new session, and AdminShell authenticates with:
Connect-ZrManager -Managers "10.0.0.10:7801" -Credential (Get-Credential) -Force
# Logged in as 'demoadmin'.
Rotate a password later with Set-ZrUserPassword.
Step 3 — Require a token on the store (data plane)
This is the step people miss. It tells the store's nodes to demand a valid token at connect.
Console — Security & TLS → Require a token to connect (per store) → enable it for the store.
PowerShell
Enable-ZrStoreSecurity -Store orders -Restart
If an orchestrator owns the nodes, the manager can't push this — the cmdlet reports "0 nodes updated" and the console shows node-config + restart. Declare the security block in each node's config and restart; see Security and TLS.
Step 4 — Encrypt the store with TLS
Turn on transport encryption. With no -Mode, MutualTls is applied node-to-node; external clients still connect with the CA plus a token and need no client certificate.
Console — Security & TLS → Encryption → enable TLS for the store. It shows a 🔒 TLS active badge.
PowerShell
Enable-ZrStoreTls -Store orders -Restart
Get-ZrStoreTlsStatus -Store orders # Mode MutualTls, PeerVerification CaAndIdentity, MinProtocol Tls12
Get-ZrClusterCaCert -OutFile cluster-ca.crt # give this to clients (or let them auto-fetch)
The store is now closed and encrypted: token required, traffic protected.
Step 5 — Issue a token for your application
A token is for an app, not a person — passwordless and scoped to a store and a data role.
Console — Security & TLS → Applications → create a service account / token for the store.
PowerShell
# A self-contained token for a subject:
New-ZrToken -Subject orders-app -Role DataWriter -Scope zaris:store:orders -LifetimeMinutes 1440
# ...or a persistent machine identity that returns a token (shown once):
New-ZrServiceAccount -Name orders-svc -Role DataWriter -Scope zaris:store:orders
Store the token in an environment variable or a Kubernetes secret — never in source.
Step 6 — Connect the application
The app presents the token (and trusts the CA). No username, no password.
$env:ORDERS_TOKEN = "<token from step 5>"
Connect-ZrStore -ConnectionString "zariss://10.0.0.10:7861/orders?token=env:ORDERS_TOKEN&ca=file:cluster-ca.crt"
Set-ZrItem -Key "customer:42" -Value '{"name":"Ada"}'
Get-ZrItem -Key "customer:42"
Without a token, the same connection is refused at the handshake with a clear reason — the data plane is closed. With the token, it succeeds. That contrast is the security model.
The .NET equivalent (connection string in appsettings.json, token from config/secret) is in Connecting a secured client and the secure .NET client tutorial.
Recap
| # | Step | Plane | Console | Cmdlet |
|---|---|---|---|---|
| 1 | Enable cluster security | Control | Overview → Enable enforcement | Initialize-ZrSecurity |
| 2 | Create an operator login | Control | People → New user | New-ZrUser |
| 3 | Require a token on the store | Data | Require a token (per store) | Enable-ZrStoreSecurity |
| 4 | Encrypt the store | Data | Encryption → enable TLS | Enable-ZrStoreTls |
| 5 | Issue an app token | Data | Applications → new token | New-ZrToken |
| 6 | Connect the app | Data | — | Connect-ZrStore -Token |
Credentials for people (steps 1–2). Tokens for apps (steps 5–6). Get that right and the rest follows.
Next steps
- Authentication and tokens — the model behind tokens and operator sign-in.
- Authorization and RBAC — the roles you assign in steps 2 and 5.
- TLS encryption and CA and trust modes — the encryption details.
- Connecting a secured client — the client side in depth.