Skip to main content
Version: 1.19.0 (latest)

Kasm Integration Deep Dive

This page explains what Kasm is doing behind the scenes when OpenZiti egress is enabled.

Integration overview​

Kasm OpenZiti support is based on a provider model:

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

Identity lifecycle​

For each enabled OpenZiti provider:

  1. Kasm identifies entitled users/workspaces from provider mappings.
  2. Kasm creates missing OpenZiti identities and enrolls them.
  3. Identity JSON is stored for launch-time use.
  4. Identities no longer entitled are removed.

Identity names are generated with Kasm metadata patterns such as:

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

Session launch behavior​

At workspace start:

  1. Sidecar receives script data for OpenZiti setup.
  2. Sidecar writes user/workspace identity JSON under: /var/run/kasm-sidecar/$container_namespace/ziti
  3. 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 and logs details for admin diagnostics.

Configuration summary​

OpenZiti configuration in Kasm is done through:

  • Infrastructure -> Egress -> Add with provider type OpenZiti.
  • OpenZiti Configuration tab on that provider for admin identity JSON.
  • Mappings to users/groups/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/Wireguard providers.

Policy expectations​

Kasm mapping grants entitlement to participate in OpenZiti identity lifecycle, but effective service access still depends on OpenZiti policy.

Typical requirements:

  • Service policy allowing managed identities to dial target services.
  • Edge-router policy allowing managed identities to use required routers.

Troubleshooting and validation​

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