Skip to main content
Version: Developer

OpenZiti zero-trust egress

OpenZiti a zero-trust egress provider supported in Kasm Workspaces. It governs how a session reaches external services by identity and policy, not by network-path selection at workspace launch.

OpenZiti extends managed egress to a model where every connection is authorized against a session identity. This keeps activity inside a governed workspace boundary while granting access to named services rather than to the network behind a gateway.

How OpenZiti differs from gateway-based egress​

Gateway-based providers (OpenVPN, Wireguard, PureVPN) tunnel the whole network path of a session through a chosen gateway. The user picks which gateway at workspace launch. OpenZiti is structured differently across four areas.

  • Service-level access, not network-path access. Each session reaches specific named services, not the network behind a gateway.
  • No launch-time gateway picker. OpenZiti policy decides which services a session can reach. Policy is evaluated against the identity of the session.
  • No per-user VPN credentials in Kasm. Kasm automates the OpenZiti identity lifecycle (create, enroll, remove) for entitled users and workspaces.
  • Per-connection authorization. OpenZiti policy evaluates every access decision against the requesting identity. As a result, the audit trail is produced as a byproduct of normal operation.

This identity-and-policy model reflects the structural shift behind zero trust. With no trusted network perimeter, every connection must independently earn authorization. Each decision is discrete, policy-bound, and logged, which makes audit straightforward.

Terminology​

Review the vocabulary below 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. A session reaches a service by name, 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 that host private services run alongside (or as) router tunnelers and Bind those services to the controller. Identities with dial permission reach those services by name. The router then routes their traffic through the encrypted fabric.

Kasm hooks in by holding an admin identity for one OpenZiti provider. Kasm uses that admin identity 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. OpenZiti policy decides whether that session can reach any given service, and Kasm never overrides that decision.

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.
  • OpenZiti providers have no per-user Egress Credential model 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​

The high-level path below covers what a deployment configures. For the full procedure, follow the quickstart linked after the 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 performs the following steps.

  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.