Skip to main content

Authorization and RBAC

Authentication establishes who the caller is. Authorization decides what that caller may do, and where. Zaris delegates authorization to its built-in security layer, which evaluates a role-based access-control (RBAC) model that is deny-by-default: a caller can do nothing until a role granted to it explicitly permits an operation at the relevant scope.

The model​

A principal from a token is granted a role at a scope; the role bundles permissions, and a deny-by-default decision permits an operation only when a granted permission covers it.

  • Permission — an operation the cluster can perform, identified by a stable id such as data.read, data.write, or store.create.
  • Role — a named set of permissions. Zaris ships a fixed catalog of preset roles; you grant these rather than individual permissions.
  • Scope — where a grant applies, as a hierarchical string: zaris:cluster for the whole cluster, or zaris:store:<name> for one store. A grant at a higher scope covers the scopes beneath it.
  • Grant — the binding itself: this role, to this principal (subject), at this scope.

Why deny-by-default​

A new principal can do nothing until a role is granted. This is the safe default: forgetting to configure a permission fails closed (access denied), never open (accidental access). It also makes audits tractable — a principal's capabilities are exactly the sum of its grants, with no ambient authority to reason about.

Permissions​

Zaris declares its permissions in a single catalog shared by the Management Service (control plane) and every node (data plane), so both resolve token roles the same way.

Control-plane permissions (enforced by the Management Service):

  • store.create, store.delete, store.start, store.stop, store.config.edit
  • node.add, node.start, node.stop
  • role.grant, role.revoke
  • diagnostics.read, metrics.read

Data-plane permissions (the store operations a node cares about):

  • data.read, data.write, data.delete, data.scan, data.clear

Preset roles​

You grant these roles by name. Each role's permission set is fixed by Zaris.

RoleScope levelPermissions
ClusterAdminclusterEvery control-plane and data-plane permission.
StoreOperatorstorestore.start, store.stop, store.config.edit, node.start, node.stop, diagnostics.read, metrics.read.
Observerstorediagnostics.read, metrics.read.
DataWriterstoredata.read, data.write, data.delete, data.scan.
DataReaderstoredata.read, data.scan.
note

These preset roles are the only roles a node can resolve offline. Custom (non-preset) roles are not resolvable at the data-plane connection check, so use the preset data roles (DataReader, DataWriter, or ClusterAdmin) for tokens that connect to a store.

How enforcement differs by plane​

Authorization is evaluated in two places, and the granularity differs.

  • Control plane (Management Service). Each management operation checks the specific permission it needs at the requested scope — for example, store.create at the cluster scope. This is fine-grained, per-operation authorization.
  • Data plane (node). A node authorizes at connection time, not per operation. When a client connects to a store, the node admits the connection if the token carries a data-capable role (DataReader, DataWriter, or ClusterAdmin) whose scope covers that store. Per-operation permission checks are intentionally kept off the data-plane hot path.

The practical consequence: to let an application connect to the orders store for reads, grant it DataReader at zaris:store:orders; to also let it write, grant DataWriter.

Granting access​

Grant and revoke roles through the Management Service (Console Security settings or the cmdlets). The grant fans out to every connected manager so the assignment is consistent cluster-wide.

# Let a service account read and write the orders store.
Grant-ZrRole -Subject orders-svc -Role DataWriter -Scope zaris:store:orders

# Give an operator cluster-wide read-only observability.
Grant-ZrRole -Subject alice -Role Observer -Scope zaris:cluster

# Remove a grant.
Revoke-ZrRole -Subject orders-svc -Role DataWriter -Scope zaris:store:orders
  • -Scope accepts a canonical scope (zaris:store:orders, zaris:cluster). A bare store name such as orders is normalized to zaris:store:orders; an empty scope or root means the cluster-wide default.
  • Inspect roles with Get-ZrRole (lists each preset role and its permissions) and audit a subject with Get-ZrGrant -Subject <subject> (its effective role, scope, and permissions).

Scopes in practice​

Scopes let one cluster safely serve many teams. A grant at a higher scope covers the scopes beneath it.

GrantEffect
DataWriter @ zaris:store:ordersread/write on orders only
DataReader @ zaris:clusterread on every store
ClusterAdmin @ zaris:clusterfull cluster administration

Next steps​