Managing multiple clusters

kixctl manages more than one Incus cluster from a single control plane. Each cluster is a row you add with its label, endpoint, and a client certificate, and it is reached over that certificate — kixctl connects over HTTPS with a scoped cert, never blanket admin.

Scope check on add

When you add or edit a cluster, kixctl runs a scope check against the certificate: a read suite that reports, per capability, what the cert can and cannot do, with plain-language remediation. A narrow certificate is surfaced up front, so it degrades predictably instead of failing at some later click.

Per-capability degradation

Degradation is per capability, not per cluster. A denied or failed read dims exactly the one dashboard area it affects, with a stated reason, rather than blanking the cluster. Reachability is a separate concern from permission, and a loop over clusters isolates failures per cluster, so one unreachable cluster never breaks the page.

The control plane cannot escalate

The certificate a cluster is reached with is scoped, and kixctl cannot widen it. Raising access is the target cluster administrator's action, surfaced with guidance — never something kixctl does to itself. This is the same invariant described in The isolation model.