Credentials and secrets

The inventory

Nothing here is omitted for looking bad.

Secret	Where it lives	Lifetime	Encrypted at rest by the application
API token (z9_live_…)	Hash only, in the control plane	Until deleted	Hash — plaintext is never stored
User session	Signed token in the browser	Short	n/a
Server password (generated)	Nowhere. Shown once	One display	n/a
SSH public key	Control plane	Until deleted	Public key; not a secret
Appliance bootstrap token	Hash in the control plane; plaintext in VM firmware metadata	Single use, minutes	Hash
Appliance device identity	Hash in the control plane; plaintext on the VM	Until the VM is rebuilt	Hash
Proxmox API token	The region agent’s environment	Until rotated	Not applicable — never in the control plane
Edge router credentials	The region agent’s environment	Until rotated	Not applicable
Zero Trust join key	Used once, discarded	Seconds	Not stored
Kubernetes kubeconfig	Control plane, until displayed once, then deleted	Until first display	No
Kubernetes cluster secrets (PKI)	Control plane	Cluster lifetime	No
Object storage cluster secret	Control plane	Store lifetime	No
Object storage access key secret	Nowhere. Shown once	One display	n/a
TLS private key	Control plane; delivered to load balancers	Certificate lifetime	No
ACME account key	Control plane	Installation lifetime	No

The rows marked No are a real gap and are tracked in Known gaps. The column names in the database already say what they are meant to become; today the value is plaintext. It is stated here rather than left to be discovered.

The rules the platform follows

Shown once, never stored. Server passwords, storage key secrets, kubeconfigs and API tokens are displayed at creation and not kept in retrievable form. Losing one means creating another. That is the deliberate trade against a control plane holding a permanent copy of every customer’s administrative credential.

Region credentials never leave the region. In agent mode the Proxmox and edge credentials exist only in the agent’s environment. Compromising the control plane does not hand over the hypervisor.

Identity is exchanged, not distributed. A fresh appliance receives a single-use bootstrap token through hypervisor firmware metadata — readable inside that guest and nowhere else — and exchanges it for a long-lived identity. The bootstrap token is consumed at that moment.

Secrets are not logged. Logs carry identifiers and outcomes. Provider tokens are never included in error messages, and the tooling used to operate the platform is held to the same rule — no tracing a script that sources a secret, no verbose HTTP dump that would print an authorization header.

Appliances cannot be logged into. No SSH daemon, no shell, no accounts. There is no interactive session on a load balancer to hijack and no shell history to read.

What you should do

Use scoped tokens. A monitoring integration gets a viewer token. Only the step that changes something needs a write token.

Rotate on suspicion, not on schedule alone. Delete first, reissue after. The audit trail shows what a token did.

Do not paste secrets into the console. Console sessions are relayed and audited. Use SSH keys for servers, and the API for everything else.

Treat a displayed secret as the only copy. The panel genuinely cannot show it again.