Skip to main content
Version: 1.19.0 (latest)

OpenZiti

OpenZiti is the first zero-trust egress provider supported in Kasm.

Unlike gateway-based providers, OpenZiti grants access by identity and policy at the service layer, not by tunnel selection at workspace launch.

How OpenZiti differs from gateway-based egress​

Gateway-based providers (OpenVPN, Wireguard, PureVPN) tunnel a session's whole network path through a chosen gateway, and the user picks which gateway at workspace launch. OpenZiti is structured differently:

  • Service-level access, not network-path access. Each session reaches specific named services, not the network behind a gateway.
  • No launch-time gateway picker. Which services a session can reach is decided by OpenZiti policy, evaluated against the session's identity.
  • No per-user VPN credentials in Kasm. Kasm automates the OpenZiti identity lifecycle (create, enroll, remove) for entitled users and workspaces.
  • Per-connection authorization. Every access decision is policy-evaluated against the requesting identity, which makes audit straightforward.

Terminology​

The vocabulary you need before reading the rest of this page or the quickstart.

  • Controller — OpenZiti control plane for identities, services, and policies.
  • Edge router — data-plane component that carries authorized traffic in the OpenZiti fabric.
  • Identity — certificate-backed user, workload, or device identity used for authentication and authorization.
  • Service — a logical target (host:port) protected by OpenZiti policies. Reached by name from a session, not by IP.
  • Dial — permission for an identity to connect to a service.
  • Bind — permission for an identity to host (provide) a service.

How it fits together​

An OpenZiti deployment has at minimum a controller and one edge router. Workloads hosting private services run alongside (or as) router tunnelers and Bind those services to the controller. Clients with dial-permitted identities reach those services by name; the router routes their traffic through the encrypted fabric.

Kasm hooks in by holding an admin identity for one OpenZiti provider and using it to manage per-user and per-workspace identities under that controller. At session launch, the sidecar drops the right identity into the session namespace and starts a Ziti tunnel inside it. Whether that session can actually reach any given service is decided by OpenZiti policy — Kasm never overrides that.

For the deeper architecture (multi-tenant networks, public/private router split, policy role design), see the kziti architecture page.

Constraints worth knowing about​

  • Provider mapping is still done in Kasm (users, groups, workspaces). Kasm decides who gets a managed identity; OpenZiti decides what each identity can reach.
  • There is no per-user Egress Credential model for OpenZiti providers, and no launch-time gateway selector.
  • A Kasm mapping without matching OpenZiti policies gives the user an enrolled identity but no service access.
  • Identity reconciliation is asynchronous — mapping changes take effect after the next reconcile cycle, not instantly.

Setup outline​

  1. Create an egress provider with type OpenZiti.
  2. Configure the OpenZiti admin identity JSON on the provider.
  3. Map the provider to users, groups, or workspaces.
  4. Configure OpenZiti policies that allow Kasm-managed identities to access target services.
  5. Launch a workspace and validate service reachability.

For an evaluation lab on a single VM, see the quickstart. For the Kasm-side internals, see the integration deep dive.

What Kasm does behind the scenes​

For each enabled OpenZiti provider, Kasm reconciles identities against entitled users and workspaces:

  1. Discover entitled users and workspaces from provider mappings.
  2. Create and enroll missing OpenZiti identities.
  3. Store the identity JSON for launch-time use.
  4. Remove identities that are no longer entitled.

At workspace launch the sidecar:

  1. Retrieves the managed identity JSON for the session.
  2. Writes the identity files under /var/run/kasm-sidecar/$container_namespace/ziti.
  3. Starts ziti tunnel run --identity-dir <path> in the session namespace.
  4. Configures DNS so Ziti name resolution works inside the session, with upstream fallback for non-Ziti destinations.

The integration deep dive covers the full identity lifecycle, naming conventions, and troubleshooting flow.