Operations with kziti

These how-to guides cover the day-to-day administration of a kziti-managed OpenZiti deployment. They assume you already have a working kziti deployment and have configured Kasm Workspaces to use OpenZiti as an egress provider.

If you have not yet read the kziti architecture page, the mental model there will make these pages easier to follow.

What's in this section

• Configure kziti — set up kziti to talk to your controller, and manage named profiles for multiple environments.
• Manage networks — create, list, and delete the private networks that group services together, and provision the private routers that host those services.
• Publish services — define services that Kasm sessions and external clients can dial through OpenZiti, and group them into service sets.
• Grant access — give a Kasm user, workspace, or external identity access to a network, service set, or individual service.
• Recover from quorum loss — restore an HA cluster after a controller has gone down without being cleanly removed.
• Remove an HA controller — cleanly remove a controller from the Raft cluster.
• Tear down a deployment — uninstall kziti from a host, with or without removing persistent data.
• kziti CLI Reference — auto-generated reference for every command, subcommand, argument, and flag.

When to reach for raw OpenZiti instead

kziti covers the operational shape described in the kziti architecture. For inspections that fall outside the kziti command surface (raw policy bodies, controller diagnostics, ZAC visualisation, and so on), the OpenZiti CLI and project tooling remain available — kziti does not hide them from you. See the architecture page for the boundary between kziti's scope and raw OpenZiti's domain.