Authentication and tokens
Two ways to authenticate
Section titled “Two ways to authenticate”A session. The console signs you in through OIDC and carries a signed session token.
An API token. Created in the panel, prefixed z9_live_, sent as a bearer token:
Authorization: Bearer z9_live_…A token belongs to an organisation and carries a role. It is shown once, when created — the panel stores only a hash, so it cannot show it to you again and neither can anyone who reaches the database.
| Role | Can |
|---|---|
owner | Everything, including managing members |
admin | Everything except changing ownership |
member | Create and modify resources |
viewer | Read only |
Write endpoints refuse a viewer token. Use one for monitoring and inspection, and only
reach for a write token in the step that actually changes something.
What the platform does with credentials
Section titled “What the platform does with credentials”These rules apply to the platform’s own handling of secrets, and they are worth knowing because they explain several product behaviours:
Shown once, never stored. Server passwords, object-storage key secrets, Kubernetes kubeconfigs and API tokens are displayed at creation and not kept in retrievable form. Losing one means creating a new one, which is the correct trade against a control plane that holds a permanent copy of every customer’s administrative credential.
Join keys are used and discarded. A Zero Trust join key you paste is used once and not stored.
Region credentials never reach the control plane. In agent mode the Proxmox and edge credentials exist only inside your region. See Trust boundaries.
Device identities are hashed. An appliance’s long-lived identity is stored as a hash; the plaintext exists only on that machine.
There is a known exception, stated here rather than buried: some secrets the platform must be able to hand back — TLS private keys, storage cluster secrets — are stored in the control plane database without application-level encryption today. See Known gaps.
Rotation
Section titled “Rotation”Create a new token, switch your automation over, delete the old one. Deletion takes effect immediately.
If a token may have leaked, delete it first and reissue afterwards. The audit trail records every action a token took, so you can determine what it was used for; see Audit trail.