Building Secure Cross-Domain Solutions with Kasm and Teleport Source

March 27, 2026 Markdown source

1---
2title: "Building Secure Cross-Domain Solutions with Kasm and Teleport"
3date: "2026-03-27"
4tags: ["kasm", "teleport", "security", "remote-desktop", "zero-trust", "cross-domain", "infrastructure"]
5author: "Gavin Jackson"
6excerpt: "How to build secure cross-domain solutions using Kasm Workspaces for isolated browser sessions and Teleport for zero-trust access control - a practical guide for organisations handling sensitive data across security boundaries."
7---
8
9# Building Secure Cross-Domain Solutions with Kasm and Teleport
10
11Cross-domain solutions are hard.
12
13Not technically impossible - we have the tools. But the combination of strict security requirements, usability concerns, and audit compliance makes them one of the more challenging infrastructure problems to solve well.
14
15I have been looking at this problem from a few angles recently. The goal: allow users to access resources in different security domains without creating pathways for data leakage or unauthorised access between those domains.
16
17Two tools have emerged as particularly useful in this space: **Kasm Workspaces** for isolated, ephemeral browser sessions, and **Teleport** for zero-trust access control and session recording.
18
19Here is how they fit together.
20
21## The Problem
22
23In many organisations - especially government, defence, finance, and healthcare - information is classified into different security domains. A user might need to:
24
25- Browse the public internet (low trust)
26- Access internal corporate systems (medium trust)
27- Work with classified or sensitive data (high trust)
28
29Traditionally, this meant air-gapped machines, multiple physical workstations, or heavily locked-down VDI environments that users hate.
30
31The modern approach is to use **isolated, ephemeral workspaces** that can be spun up on demand, used for a specific task, and then destroyed - leaving no persistent data on the endpoint.
32
33## Kasm Workspaces: The Isolation Layer
34
35Kasm Workspaces is an open-source (with commercial support) container streaming platform. It delivers browser-based access to isolated applications and desktops running in Docker containers.
36
37### Why Kasm Works for Cross-Domain
38
39**Ephemeral by design:** Every session starts fresh from a clean image. When the user closes the browser tab, the container is destroyed. No persistence, no malware surviving reboots, no data left behind.
40
41**Browser-based access:** Users do not install anything. They open a URL, authenticate, and get a fully functional Linux desktop or single application streaming to their browser via WebRTC.
42
43**Granular images:** You can define different images for different trust levels:
44- A hardened Chrome image for general web browsing
45- A Firefox image with specific extensions for research
46- A full Ubuntu desktop for development work
47- A locked-down image with no clipboard, no downloads, no printing for highly sensitive access
48
49**Network segmentation:** Each Kasm agent can be placed in a different network segment. The workspace container only has access to the networks you explicitly allow.
50
51### Setting Up Domain Isolation
52
53The key architectural decision is mapping Kasm workspaces to security domains:
54
55```text
56+-------------------------------------------------------------+
57|                         Kasm Manager                        |
58|                  (Orchestration and User Auth)              |
59+-------------------------------------------------------------+
60                              |
61         +--------------------+--------------------+
62         v                    v                    v
63+---------------+    +---------------+    +---------------+
64|  Kasm Agent   |    |  Kasm Agent   |    |  Kasm Agent   |
65|   (Domain A)  |    |   (Domain B)  |    |   (Domain C)  |
66|  Internet     |    |  Corporate    |    |  Classified   |
67|  Zone         |    |  Network      |    |  Network      |
68+---------------+    +---------------+    +---------------+
69```
70
71Each Kasm agent runs on a host with specific network connectivity. The "Internet Zone" agent has outbound internet access. The "Classified Network" agent only has access to classified resources. The user chooses (or is assigned) the appropriate workspace based on their current task.
72
73### Kasm Configuration Tips
74
75**Disable persistence features for high-trust domains:**
76
77```yaml
78# In your Kasm image configuration
79persistent_profile: false
80enable_clipboard: false
81enable_downloads: false
82enable_uploads: false
83```
84
85**Use network policies to restrict container egress:**
86
87```yaml
88# Docker daemon configuration or Kubernetes network policies
89egress:
90  - to:
91    - namespaceSelector:
92        matchLabels:
93          domain: classified-resources
94```
95
96**Enable session recording for audit trails:**
97
98Kasm can record sessions as video files, which is useful for compliance. But for a more integrated approach, we bring in Teleport.
99
100## Teleport: The Access Control Layer
101
102Teleport is an open-source (with enterprise features) access platform that provides:
103
104- **Certificate-based authentication:** No static credentials, short-lived certificates
105- **Role-based access control (RBAC):** Fine-grained permissions based on identity
106- **Session recording:** Complete audit trail of every command, query, or desktop session
107- **Just-in-time access:** Request and approve access workflows
108- **Unified access:** One tool for SSH, Kubernetes, databases, applications, and desktops
109
110### Why Teleport Complements Kasm
111
112While Kasm provides isolation, Teleport provides **identity, audit, and policy enforcement**.
113
114**Unified identity:** Teleport can act as the identity provider for Kasm, or integrate with your existing IdP (Okta, Azure AD, etc.) and pass identity attributes through to Kasm.
115
116**Policy enforcement:** Teleport's RBAC can determine which users can access which Kasm workspaces based on labels, time of day, and approval workflows.
117
118**Enhanced audit:** Teleport records not just that a user accessed Kasm, but what they did inside the session - with structured logs that integrate with SIEM tools.
119
120**Secure bastion:** Teleport can act as the only entry point to your Kasm infrastructure, eliminating exposed Kasm manager interfaces.
121
122## Integrating Kasm with Teleport
123
124The cleanest way to combine the two is to make Teleport the front door and policy layer for every Kasm environment. Users authenticate to Teleport first, then launch the Kasm workspace that matches the domain they are allowed to access.
125
126That keeps the access path consistent:
127
128```text
129User -> Teleport Proxy -> Kasm Manager -> Kasm Agent (Domain X)
130```
131
132Teleport decides which Kasm applications appear to the user, enforces MFA and session limits, and records the access event. Kasm then provides the isolated workspace inside the correct network segment.
133
134## Putting It Together: A Reference Architecture
135
136Here is what that deployment looks like in practice for a three-domain cross-domain solution:
137
138```text
139+---------------------------------------------------------------------+
140|                         User Workstation                            |
141|                    (No special software installed)                  |
142+---------------------------------------------------------------------+
143                                |
144                                v
145+---------------------------------------------------------------------+
146|                      Teleport Proxy Cluster                         |
147|         (Public-facing, MFA-required, session recording)            |
148+---------------------------------------------------------------------+
149                                |
150         +----------------------+----------------------+ 
151         v                      v                      v
152+---------------+      +---------------+      +---------------+
153|  Kasm Agent   |      |  Kasm Agent   |      |  Kasm Agent   |
154|  (Domain A)   |      |  (Domain B)   |      |  (Domain C)   |
155|               |      |               |      |               |
156| - Internet    |      | - Corporate   |      | - Classified  |
157|   access      |      |   apps        |      |   resources   |
158| - No VPN      |      | - Internal    |      | - Restricted  |
159|   needed      |      |   databases   |      |   egress      |
160|               |      |               |      |               |
161| Labels:       |      | Labels:       |      | Labels:       |
162|   domain=web  |      |   domain=corp |      |   domain=sec  |
163+---------------+      +---------------+      +---------------+
164```
165
166In this model, each Kasm manager endpoint is published into Teleport as an application with labels that represent the relevant domain and classification. Users never browse directly to Kasm. They go through Teleport, which becomes the single access path for internet, corporate, and classified workspaces.
167
168### Teleport Application Mapping
169
170```yaml
171# teleport.yaml app configuration
172app_service:
173  enabled: true
174  apps:
175    - name: kasm-internet
176      uri: https://kasm-manager.domain-a.internal
177      labels:
178        domain: web
179        classification: unclassified
180
181    - name: kasm-corporate
182      uri: https://kasm-manager.domain-b.internal
183      labels:
184        domain: corp
185        classification: internal
186
187    - name: kasm-classified
188      uri: https://kasm-manager.domain-c.internal
189      labels:
190        domain: sec
191        classification: secret
192```
193
194From the user side, the experience stays simple:
195
196```bash
197# List available Kasm environments
198tsh apps ls
199
200# Launch the classified Kasm environment
201tsh app launch kasm-classified
202```
203
204### Teleport RBAC Mapping
205
206```yaml
207# Role: general-user
208allow:
209  app_labels:
210    domain: ["web", "corp"]
211
212# Role: cleared-researcher
213allow:
214  app_labels:
215    domain: ["web", "corp", "sec"]
216  require_session_mfa: hardware
217  request_access: optional
218
219# Role: admin
220deny:
221  app_labels:
222    domain: ["sec"]  # Admins don't automatically get classified access
223```
224
225### Data Flow Controls
226
227To prevent data exfiltration between domains:
228
2291. **Kasm-level:** Disable clipboard, file upload/download, printing for high-trust domains
2302. **Network-level:** Strict egress filtering from Kasm agents - only allow connections to known resources
2313. **Teleport-level:** Session recording, identity-aware access policies, and detailed audit logs
2324. **Process-level:** DLP scanning on any approved export pathways (if required)
233
234## Operational Considerations
235
236### Performance
237
238Kasm streams desktop environments via WebRTC. For acceptable performance:
239- Kasm agents should be geographically close to users
240- Allocate sufficient CPU/memory for concurrent sessions
241- Use GPU acceleration for video-heavy workloads
242
243Teleport adds minimal latency for application access but can proxy desktop protocols if needed.
244
245### Scaling
246
247- **Kasm:** Scale agents horizontally based on concurrent session demand
248- **Teleport:** Proxy cluster can scale behind a load balancer; auth service is the bottleneck (usually fine for thousands of users)
249
250### Backup and Disaster Recovery
251
252- Kasm workspaces are ephemeral - no backup needed
253- Kasm configuration (images, settings) should be in Git/IaC
254- Teleport cluster state should be backed up (etcd or DynamoDB depending on deployment)
255
256### Monitoring
257
258Key metrics to track:
259- Concurrent Kasm sessions per domain
260- Session duration and idle time
261- Teleport authentication failures
262- Resource access patterns (unusual database queries, etc.)
263
264## Conclusion
265
266Cross-domain solutions do not have to mean clunky VDI or multiple physical machines. With Kasm Workspaces for isolation and Teleport for access control, you can build a modern, user-friendly system that satisfies security requirements without making users miserable.
267
268This approach gives you:
269- **Ephemeral, isolated workspaces** per security domain
270- **Zero-trust access** with short-lived certificates
271- **Complete audit trails** for compliance
272- **Browser-based access** - no client software to manage
273- **Granular controls** over data flow between domains
274
275It is not a turnkey solution - you still need to design your network segmentation, define your RBAC policies, and train your users. But the tools are there, they are open source (with commercial support options), and they work.
276
277If you are wrestling with cross-domain access problems, this stack is worth evaluating.
278
279---
280
281**Resources:**
282- [Kasm Workspaces](https://www.kasmweb.com/)
283- [Teleport](https://goteleport.com/)
284- [Kasm Documentation - Workspaces](https://www.kasmweb.com/docs/latest/index.html)
285- [Teleport Documentation - Architecture](https://goteleport.com/docs/architecture/)
286

---
title: "Building Secure Cross-Domain Solutions with Kasm and Teleport"
date: "2026-03-27"
tags: ["kasm", "teleport", "security", "remote-desktop", "zero-trust", "cross-domain", "infrastructure"]
author: "Gavin Jackson"
excerpt: "How to build secure cross-domain solutions using Kasm Workspaces for isolated browser sessions and Teleport for zero-trust access control - a practical guide for organisations handling sensitive data across security boundaries."
---

# Building Secure Cross-Domain Solutions with Kasm and Teleport

Cross-domain solutions are hard.

Not technically impossible - we have the tools. But the combination of strict security requirements, usability concerns, and audit compliance makes them one of the more challenging infrastructure problems to solve well.

I have been looking at this problem from a few angles recently. The goal: allow users to access resources in different security domains without creating pathways for data leakage or unauthorised access between those domains.

Two tools have emerged as particularly useful in this space: **Kasm Workspaces** for isolated, ephemeral browser sessions, and **Teleport** for zero-trust access control and session recording.

Here is how they fit together.

## The Problem

In many organisations - especially government, defence, finance, and healthcare - information is classified into different security domains. A user might need to:

- Browse the public internet (low trust)
- Access internal corporate systems (medium trust)
- Work with classified or sensitive data (high trust)

Traditionally, this meant air-gapped machines, multiple physical workstations, or heavily locked-down VDI environments that users hate.

The modern approach is to use **isolated, ephemeral workspaces** that can be spun up on demand, used for a specific task, and then destroyed - leaving no persistent data on the endpoint.

## Kasm Workspaces: The Isolation Layer

Kasm Workspaces is an open-source (with commercial support) container streaming platform. It delivers browser-based access to isolated applications and desktops running in Docker containers.

### Why Kasm Works for Cross-Domain

**Ephemeral by design:** Every session starts fresh from a clean image. When the user closes the browser tab, the container is destroyed. No persistence, no malware surviving reboots, no data left behind.

**Browser-based access:** Users do not install anything. They open a URL, authenticate, and get a fully functional Linux desktop or single application streaming to their browser via WebRTC.

**Granular images:** You can define different images for different trust levels:
- A hardened Chrome image for general web browsing
- A Firefox image with specific extensions for research
- A full Ubuntu desktop for development work
- A locked-down image with no clipboard, no downloads, no printing for highly sensitive access

**Network segmentation:** Each Kasm agent can be placed in a different network segment. The workspace container only has access to the networks you explicitly allow.

### Setting Up Domain Isolation

The key architectural decision is mapping Kasm workspaces to security domains:

```text
+-------------------------------------------------------------+
|                         Kasm Manager                        |
|                  (Orchestration and User Auth)              |
+-------------------------------------------------------------+
                              |
         +--------------------+--------------------+
         v                    v                    v
+---------------+    +---------------+    +---------------+
|  Kasm Agent   |    |  Kasm Agent   |    |  Kasm Agent   |
|   (Domain A)  |    |   (Domain B)  |    |   (Domain C)  |
|  Internet     |    |  Corporate    |    |  Classified   |
|  Zone         |    |  Network      |    |  Network      |
+---------------+    +---------------+    +---------------+
```

Each Kasm agent runs on a host with specific network connectivity. The "Internet Zone" agent has outbound internet access. The "Classified Network" agent only has access to classified resources. The user chooses (or is assigned) the appropriate workspace based on their current task.

### Kasm Configuration Tips

**Disable persistence features for high-trust domains:**

```yaml
# In your Kasm image configuration
persistent_profile: false
enable_clipboard: false
enable_downloads: false
enable_uploads: false
```

**Use network policies to restrict container egress:**

```yaml
# Docker daemon configuration or Kubernetes network policies
egress:
  - to:
    - namespaceSelector:
        matchLabels:
          domain: classified-resources
```

**Enable session recording for audit trails:**

Kasm can record sessions as video files, which is useful for compliance. But for a more integrated approach, we bring in Teleport.

## Teleport: The Access Control Layer

Teleport is an open-source (with enterprise features) access platform that provides:

- **Certificate-based authentication:** No static credentials, short-lived certificates
- **Role-based access control (RBAC):** Fine-grained permissions based on identity
- **Session recording:** Complete audit trail of every command, query, or desktop session
- **Just-in-time access:** Request and approve access workflows
- **Unified access:** One tool for SSH, Kubernetes, databases, applications, and desktops

### Why Teleport Complements Kasm

While Kasm provides isolation, Teleport provides **identity, audit, and policy enforcement**.

**Unified identity:** Teleport can act as the identity provider for Kasm, or integrate with your existing IdP (Okta, Azure AD, etc.) and pass identity attributes through to Kasm.

**Policy enforcement:** Teleport's RBAC can determine which users can access which Kasm workspaces based on labels, time of day, and approval workflows.

**Enhanced audit:** Teleport records not just that a user accessed Kasm, but what they did inside the session - with structured logs that integrate with SIEM tools.

**Secure bastion:** Teleport can act as the only entry point to your Kasm infrastructure, eliminating exposed Kasm manager interfaces.

## Integrating Kasm with Teleport

The cleanest way to combine the two is to make Teleport the front door and policy layer for every Kasm environment. Users authenticate to Teleport first, then launch the Kasm workspace that matches the domain they are allowed to access.

That keeps the access path consistent:

```text
User -> Teleport Proxy -> Kasm Manager -> Kasm Agent (Domain X)
```

Teleport decides which Kasm applications appear to the user, enforces MFA and session limits, and records the access event. Kasm then provides the isolated workspace inside the correct network segment.

## Putting It Together: A Reference Architecture

Here is what that deployment looks like in practice for a three-domain cross-domain solution:

```text
+---------------------------------------------------------------------+
|                         User Workstation                            |
|                    (No special software installed)                  |
+---------------------------------------------------------------------+
                                |
                                v
+---------------------------------------------------------------------+
|                      Teleport Proxy Cluster                         |
|         (Public-facing, MFA-required, session recording)            |
+---------------------------------------------------------------------+
                                |
         +----------------------+----------------------+ 
         v                      v                      v
+---------------+      +---------------+      +---------------+
|  Kasm Agent   |      |  Kasm Agent   |      |  Kasm Agent   |
|  (Domain A)   |      |  (Domain B)   |      |  (Domain C)   |
|               |      |               |      |               |
| - Internet    |      | - Corporate   |      | - Classified  |
|   access      |      |   apps        |      |   resources   |
| - No VPN      |      | - Internal    |      | - Restricted  |
|   needed      |      |   databases   |      |   egress      |
|               |      |               |      |               |
| Labels:       |      | Labels:       |      | Labels:       |
|   domain=web  |      |   domain=corp |      |   domain=sec  |
+---------------+      +---------------+      +---------------+
```

In this model, each Kasm manager endpoint is published into Teleport as an application with labels that represent the relevant domain and classification. Users never browse directly to Kasm. They go through Teleport, which becomes the single access path for internet, corporate, and classified workspaces.

### Teleport Application Mapping

```yaml
# teleport.yaml app configuration
app_service:
  enabled: true
  apps:
    - name: kasm-internet
      uri: https://kasm-manager.domain-a.internal
      labels:
        domain: web
        classification: unclassified

    - name: kasm-corporate
      uri: https://kasm-manager.domain-b.internal
      labels:
        domain: corp
        classification: internal

    - name: kasm-classified
      uri: https://kasm-manager.domain-c.internal
      labels:
        domain: sec
        classification: secret
```

From the user side, the experience stays simple:

```bash
# List available Kasm environments
tsh apps ls

# Launch the classified Kasm environment
tsh app launch kasm-classified
```

### Teleport RBAC Mapping

```yaml
# Role: general-user
allow:
  app_labels:
    domain: ["web", "corp"]

# Role: cleared-researcher
allow:
  app_labels:
    domain: ["web", "corp", "sec"]
  require_session_mfa: hardware
  request_access: optional

# Role: admin
deny:
  app_labels:
    domain: ["sec"]  # Admins don't automatically get classified access
```

### Data Flow Controls

To prevent data exfiltration between domains:

1. **Kasm-level:** Disable clipboard, file upload/download, printing for high-trust domains
2. **Network-level:** Strict egress filtering from Kasm agents - only allow connections to known resources
3. **Teleport-level:** Session recording, identity-aware access policies, and detailed audit logs
4. **Process-level:** DLP scanning on any approved export pathways (if required)

## Operational Considerations

### Performance

Kasm streams desktop environments via WebRTC. For acceptable performance:
- Kasm agents should be geographically close to users
- Allocate sufficient CPU/memory for concurrent sessions
- Use GPU acceleration for video-heavy workloads

Teleport adds minimal latency for application access but can proxy desktop protocols if needed.

### Scaling

- **Kasm:** Scale agents horizontally based on concurrent session demand
- **Teleport:** Proxy cluster can scale behind a load balancer; auth service is the bottleneck (usually fine for thousands of users)

### Backup and Disaster Recovery

- Kasm workspaces are ephemeral - no backup needed
- Kasm configuration (images, settings) should be in Git/IaC
- Teleport cluster state should be backed up (etcd or DynamoDB depending on deployment)

### Monitoring

Key metrics to track:
- Concurrent Kasm sessions per domain
- Session duration and idle time
- Teleport authentication failures
- Resource access patterns (unusual database queries, etc.)

## Conclusion

Cross-domain solutions do not have to mean clunky VDI or multiple physical machines. With Kasm Workspaces for isolation and Teleport for access control, you can build a modern, user-friendly system that satisfies security requirements without making users miserable.

This approach gives you:
- **Ephemeral, isolated workspaces** per security domain
- **Zero-trust access** with short-lived certificates
- **Complete audit trails** for compliance
- **Browser-based access** - no client software to manage
- **Granular controls** over data flow between domains

It is not a turnkey solution - you still need to design your network segmentation, define your RBAC policies, and train your users. But the tools are there, they are open source (with commercial support options), and they work.

If you are wrestling with cross-domain access problems, this stack is worth evaluating.

---

**Resources:**
- [Kasm Workspaces](https://www.kasmweb.com/)
- [Teleport](https://goteleport.com/)
- [Kasm Documentation - Workspaces](https://www.kasmweb.com/docs/latest/index.html)
- [Teleport Documentation - Architecture](https://goteleport.com/docs/architecture/)