Planning and Design Concepts
About This Article
This series of explanation articles is written for Enterprise Architects evaluating or planning Kasm Workspaces deployments. Each article is understanding oriented: the goal is to build a durable mental model of how and why the architecture is structured the way it is. These articles are not deployment guides, configuration references, or operational runbooks.
Zero Trust Workspace Delivery for the Modern Enterprise
If your background includes Citrix Virtual Apps and Desktops, Omnissa Horizon, Azure Virtual Desktop, or Amazon WorkSpaces, most of what you already know about workspace architecture still applies here. Concepts like session brokering, connection gateways, and resource pools all have a counterpart in Kasm Workspaces. What differs is where the platform draws its security boundary, and that difference is worth understanding before you map your existing design patterns onto it.
This article builds the conceptual foundation that makes every later architecture decision easier to reason about. Understanding why the platform is structured this way will make the configuration decisions in later articles more straightforward.
The Problem Kasm Was Built to Solve
Kasm Workspaces extends familiar workspace delivery concepts to address a specific, well documented enterprise problem: providing secure, reliable access to applications and desktops for users connecting from any device, on any network, while containing the risk that comes with that flexibility. It does this using standard, well established web technologies rather than a proprietary client stack:
- HTTPS-based session delivery
- High-performance WebSocket streaming
- Browser-native authentication and access control
- All execution is performed in secure infrastructure, not on endpoints
- Pixel rendering is performed client-side in the browser
- No proprietary client software or endpoint agent required
Why Legacy VDI and VPN Models Reach Their Limits
Traditional workspace delivery platforms were designed around assumptions that were reasonable at the time but have become harder to satisfy in most modern enterprises:
- Users connect from trusted networks or managed corporate endpoints
- Security enforcement occurs at the network perimeter
- VPN-based access is an acceptable mechanism for remote workers
Each of these assumptions is harder to guarantee in environments that support hybrid workforces, third-party contractors, unmanaged devices, or data subject to Data Loss Prevention (DLP) requirements. VPN-based access extends the internal network to the endpoint, which increases the blast radius of an endpoint compromise and creates a path for lateral movement. Legacy VDI reduces some of this risk, but it still typically depends on proprietary client software, persistent desktops that accumulate state across sessions, and trust models that treat network location as a proxy for legitimacy.
Kasm Workspaces was built to close this gap: to give architects a workspace delivery model that holds up under a Zero Trust standard, where every access request is validated on its own merits regardless of where it originates, without requiring a wholesale replacement of existing identity, security, and infrastructure investments.
The Architectural Principle: Execution Stays in Infrastructure
The organizing principle behind Kasm Workspaces can be stated directly:
Workloads execute in secure infrastructure environments, not on user devices.
In conventional VDI, the virtual machine is a full, persistent environment, and client software on the endpoint renders its output. The endpoint remains a meaningful participant: it can hold client certificates, run a proprietary protocol stack, and retain session data.
In Kasm Workspaces, the endpoint functions as a display device. Its role is limited to rendering a pixel stream delivered from infrastructure the organization controls. The endpoint does not execute the application, does not touch the underlying data directly, and does not retain session state once the session ends.
| Architectural Advantage | What It Means in Practice |
|---|---|
| Reduced endpoint attack surface | A compromised endpoint cannot compromise the workspace, because execution happens entirely in infrastructure |
| Isolation of untrusted content | Code, files, and browser activity run inside an ephemeral container that is destroyed at session end |
| Centralized execution control | Policy is enforced in infrastructure, independent of endpoint state or management enrollment |
| Elimination of persistent state | Sessions are disposable by design, removing the kind of persistent foothold that Advanced Persistent Threats (APTs) rely on |
Web-Native, Standards-Based Delivery
Web-native has a precise meaning here. It does not describe a product with a web interface layered on top of a proprietary protocol stack. It describes a delivery architecture where every component, from session origin to browser rendering, runs on standard, open web technologies, with no proprietary protocol in the user-facing path. That distinction matters operationally: it is what keeps firewall rules simple and keeps the platform interoperable with the identity, logging, and security tooling you already run.
When a user authenticates to Kasm Workspaces, the entire session lifecycle runs over HTTPS and WebSocket:
| Step | What Happens | Technology |
|---|---|---|
| 1 | User navigates to the Kasm URL in any modern browser | HTTPS |
| 2 | Browser authenticates against kasm_api via identity provider | HTTPS REST, SAML, or OIDC |
| 3 | kasm_manager schedules a container on an available Agent node | Internal API |
| 4 | Browser opens a WebSocket stream via kasm_proxy to the container | WebSocket over HTTPS |
| 5 | Session is rendered client-side inside the browser tab | HTML5 Canvas |
| 6 | Session ends; container is destroyed; no persistent state remains | Docker lifecycle |
The practical result is a simple, auditable network requirement: the complete user-facing firewall rule is a single outbound allow on port 443. There is no VPN client to install, no persistent tunnel to maintain, and no proprietary protocol handshake to support. The browser's native security sandbox becomes part of the session security boundary by design.
The single-port requirement applies to traffic between end users and the Kasm platform. Internal component networking uses standard protocol ports: TCP 5432 for PostgreSQL, TCP 3389 for RDP to legacy targets, TCP 22 for SSH, and TCP 5900 for VNC. These are intra-infrastructure paths, not user-facing firewall requirements.
For legacy protocols such as RDP, VNC, and SSH, Kasm does not stream those protocols directly to the browser. The Connection Proxy role translates them server-side into a browser-renderable WebSocket stream before delivery. From the browser's perspective, every session arrives over the same HTTPS and WebSocket path, which means existing network monitoring and inspection tools continue to work as expected.
Zero Trust Alignment: Architecture as Security Policy
Zero Trust is an architectural approach built on one foundational assumption: breach is possible, so containment matters as much as prevention. Kasm Workspaces is designed at the architecture level to support the controls a Zero Trust standard requires, rather than adding those controls on top of an existing design.
| Zero Trust Control | How Kasm Implements It |
|---|---|
| Least Privilege Access | Users receive a session, not network access. Access is scoped to the specific workspace policy assigned to them |
| Micro-segmentation | Each session container has its own Linux kernel namespace. Sessions cannot communicate with each other at the network layer |
| Elimination of Implicit Trust | Each session is individually authenticated and authorized. There is no persistent authenticated tunnel that carries over between sessions |
| Attack Surface Reduction | The session container is destroyed on logout, removing all residual state. The browser sandbox is the outermost boundary |
| Embedded DLP | Clipboard access, file upload, and file download are configurable per workspace policy, enforced at the session boundary regardless of endpoint state |
In many traditional VDI environments, DLP is added on top of the system through endpoint agents, network inspection appliances, and after-the-fact monitoring. All of these approaches share the same dependency: they rely on the endpoint and network being in a known, trusted state. In Kasm Workspaces, DLP is a property of how sessions are delivered, applied uniformly across managed and unmanaged devices alike.
The Two Traffic Planes
One of the most useful distinctions to internalize in Kasm Workspaces is the separation between two different types of traffic. Every topology and placement decision in this reference architecture series traces back to this separation.
| Characteristic | Control Plane | Session Plane |
|---|---|---|
| Content | Authentication, policy evaluation, session orchestration, workspace lifecycle | Live pixel stream, keyboard and mouse input, clipboard events, file transfer |
| Bandwidth profile | Low: primarily API call volume | High: approximately 5 to 15 Mbps per active session |
| Latency sensitivity | Database query latency: slow queries degrade launch times for all users at once | Network round-trip between the proxy and the user's browser: high latency produces visible display lag |
| Database dependency | Yes: multiple sequential, blocking queries per operation | None: zero database interaction during an active session stream |
| Handled by | Web App role | Kasm Agent role or Connection Proxy role |
These two planes pull infrastructure in opposite directions in any distributed deployment:
- Control plane traffic anchors the Web App role near the database. Placing the Web App role far from the database introduces latency that degrades the experience for every user in every zone at once.
- Session plane traffic benefits from proxy nodes placed as close as possible to end users. A Kasm Dedicated Proxy node can sit in a geographically remote region with no control plane penalty, because it has zero database dependency.
This distinction is the practical justification for the Dedicated Proxy role, and the reason a multi-zone deployment can support global geographic distribution without needing a full control plane replica in every region.
The Five Service Roles and Their Responsibilities
Kasm Workspaces uses a role-based architecture. A role is a collection of services with a defined responsibility boundary. Roles can be co-located on a single server, as in a single-server deployment, or distributed across many servers, as in larger multi-server deployments. The same role definitions apply either way.
| Role | Key Services | TCP Port | Zone-Assigned | Database Dependency |
|---|---|---|---|---|
| Web App | kasm_api, kasm_manager, kasm_proxy | 443 | Yes | Critical |
| Database | kasm_db (PostgreSQL) | 5432 | No | N/A |
| Agent | kasm_agent, kasm_proxy, container runtime | 443 | Yes | None |
| Connection Proxy | kasm_guac, kasm_rdp_gateway, kasm_rdp_https_gateway, kasm_proxy | 22, 443, 3389, 5900 | Yes | None |
| Dedicated Proxy | kasm_proxy | 443 | Yes | None |
Understanding these roles as a system, rather than as individual services, is the key to reading any Kasm reference architecture diagram correctly.
The Deployment Patterns
Kasm architectures grow through progressive separation of concerns. Each stage adds resilience, scalability, and architectural clarity. This is not a forced upgrade path: each stage is appropriate for a specific scale and fault-tolerance requirement, and many organizations run successfully at an earlier stage indefinitely.
| Architecture | DB Proximity | Zone Count | Fault Tolerance | Primary Use Case |
|---|---|---|---|---|
| RA1: Single Server | Automatic (same host) | 1 | None | POC, dev/test, small teams, edge sites |
| RA2: Single Server Control Plane + External Agents | Automatic (co-located) | 1 | Agent tier only | Capacity expansion, legacy access in remote networks |
| RA3: Single Zone Multi-Server | Deliberate (same DC or region) | 1 | All roles | Enterprise: Single region |
| RA4: Multi-Zone Multi-Server | Deliberate (same DC or region) | 1 per region | All roles + zone isolation | Enterprise: Global multi-region |
The transitions between stages are additive rather than a replacement. Moving from RA2 to RA3 means separating the database onto a dedicated server and adding a second Web App node behind a load balancer. Moving from RA3 to RA4 means defining additional zones with region-specific infrastructure, while keeping the Web App role and database anchored at the central site.
Architecture selection is driven by session concurrency, fault tolerance, and geographic distribution requirements. The choice of hypervisor or cloud provider does not determine which reference architecture to select.
What This Means for Your Evaluation
None of the roles, planes, or deployment patterns above require you to set aside your existing standards. Kasm Workspaces is designed to integrate with the identity providers, logging systems, and infrastructure platforms your organization already runs, and to scale from a single-server proof of concept to a global, multi-region deployment using the same underlying architecture. Each reference architecture in this series documents a proven, supportable pattern used in production today, so you can select the stage that matches your current requirements and grow into the next one when you need it, without redesigning the platform from scratch.
Proceed to the following sections that build on these foundations.