Skip to main content
Version: Developer

OpenZiti egress in Kasm Workspaces: integration deep dive

This page explains what Kasm Workspaces does behind the scenes when OpenZiti egress is enabled. OpenZiti egress is one of Kasm's managed egress options. It governs how workspace sessions reach external services through a zero-trust overlay network rather than a gateway-based tunnel.

For the high-level comparison, see how OpenZiti differs from gateway-based egress.

Integration overview​

Kasm OpenZiti support is based on a provider model. The model has four moving parts:

  • An egress provider of type OpenZiti is configured in Kasm.
  • An OpenZiti admin identity is stored on that provider.
  • Kasm periodically reconciles entitled users and workspaces to manage OpenZiti identities.
  • At session launch, the sidecar injects identity files and starts ziti tunnel run.

This design keeps identity management centralized. Administrators map entitlements once, and Kasm maintains the underlying OpenZiti identities automatically.

Identity lifecycle​

Kasm runs a reconciliation loop for each enabled OpenZiti provider. The loop performs four actions:

  1. Kasm identifies entitled users and workspaces from provider mappings.
  2. Kasm creates missing OpenZiti identities and enrolls them.
  3. Kasm stores the identity JSON for launch-time use.
  4. Kasm removes identities that are no longer entitled.

Identity names follow Kasm metadata patterns. The patterns make managed identities easy to recognize in OpenZiti:

  • kasm-user-<username>-<user-id-prefix>-<provider-id-prefix>
  • kasm-workspace-<workspace-name>-<image-id-prefix>-<provider-id-prefix>

Session launch behavior​

The sidecar performs the OpenZiti setup when a workspace starts. Startup follows four steps:

  1. The sidecar receives script data for OpenZiti setup.
  2. The sidecar writes user or workspace identity JSON under /var/run/kasm-sidecar/$container_namespace/ziti.
  3. The sidecar starts ziti tunnel run --identity-dir <path>.
  4. DNS behavior is updated so Ziti name resolution functions inside the session namespace.

If tunnel startup fails, session startup reports an egress-related error. Kasm also logs the details for administrator diagnostics.

Configuration summary​

OpenZiti configuration in Kasm uses three elements:

  • Infrastructure -> Egress -> Add with provider type OpenZiti.
  • The OpenZiti Configuration tab on that provider for the admin identity JSON.
  • Mappings to users, groups, and workspaces that should receive OpenZiti access.
Credential model difference

OpenZiti does not use per-user Egress Credentials or gateway selection in the same way as OpenVPN and WireGuard providers.

Policy expectations​

A Kasm mapping grants entitlement to participate in the OpenZiti identity lifecycle. Effective service access still depends on OpenZiti policy.

Two policies are typically required:

  • A service policy allowing managed identities to dial target services.
  • An edge-router policy allowing managed identities to use required routers.

Troubleshooting and validation​

Use the following checks to confirm the integration is working as expected:

  • Confirm the provider type is OpenZiti and the configuration is present.
  • Confirm identities are created in OpenZiti after mappings and reconciliation.
  • Confirm policy roles include the expected Kasm-managed identity names.
  • Check the logs:
    • /var/log/kasm-sidecar/network_sidecar.log
    • /var/run/kasm-sidecar/$container_namespace/ziti.log