4SO LabThe endpoint is not the place of trust
The session and workload execution stay in a controlled environment; the endpoint is only the interaction layer.
ZERO-TRUST WORKSPACE DELIVERY
4SO WorkspaceSecure Browser-delivered Workspaces
Workspace separates the work environment and remote access from the user's endpoint; identity, policy, DLP, scheduling, session and execution sit in one manageable product model.
Linux WorkspacesRDP / VNC / SSHDLP & PolicyMulti-zone
4SO Workspace components: browser, policy, and separate control and execution planes
- 1User browserAuthenticate, pick a workspace and launch or resume a session in a modern browser.
- 2Identity & policyEnterprise identity, RBAC and DLP decide what a session may do: clipboard, files, network and peripherals.
- 3Control PlaneGo services own scheduling, lifecycle and audit; PostgreSQL is the state authority.
- 4mTLS node agentNode management is outbound-first and mTLS-authenticated: observed state, bounded execution.
- 5Execution PlaneIsolated Linux workspaces stream through KasmVNC; Docker Engine is the first runtime provider.
- 6RDP / VNC / SSHBrowser access to existing systems through the Apache Guacamole ecosystem.
01PROBLEM & OUTCOME
Product problem
Secure access gets hard when work runs on a trusted endpoint.
Teams usually run separate tools for Browser, Desktop, Remote Access, Policy and Session. Workspace brings them under one unified experience and separates protected execution from the user's device.
One entry point for several workspace types
Browser, Linux Desktop/Application and RDP/VNC/SSH are all available from one web experience.
Policy is part of the execution environment
DLP, Identity, Network Path and Peripheral access are built into the product model.
Session infrastructure is manageable
Capacity, nodes, Scheduling, Audit and lifecycle are managed from the operator panel.
02CAPABILITY SNAPSHOT
Capability snapshot
A simple user experience, serious infrastructure behind it.
Workspace keeps User Experience and Infrastructure Operations capabilities side by side in one product.
Browser, Desktop and App
Disposable Linux environments for everyday work and controlled workloads.
RDP / VNC / SSH
Access to existing systems through the browser, without scattered clients.
Enterprise identity and access
Authentication, Authorization and scope for users and operators.
Policy and data control
File, Clipboard, Peripheral and Network Path can be controlled by Policy.
Scheduling and Capacity
Execution node selection, capacity and scale based on infrastructure state.
Multi-zone Operation
Extend the Execution Plane without turning the Control Plane into a workload runtime.
Recording and Collaboration
Session-level capabilities for observation, collaboration and Audit.
Health, Capacity and Audit
Operators follow infrastructure and session lifecycle from a single view.
4SO
Control Plane and Execution Plane are two independent roles. Workspace Intent is not locked to a specific execution environment; Single-node is a first-class deployment model.
03TOPOLOGY / DEPLOYMENT MODEL
Deployment model
From a single server to a multi-zone Execution Plane.
The deployment model starts with one server and grows by adding execution nodes. Kubernetes is a deployment option, not a prerequisite for the user experience.
| Profile | Control Plane | Execution | Use |
|---|---|---|---|
| Single node | Same server | Same server | Simple start and small environments |
| Control + execution nodes | Dedicated Control Plane | Multiple execution nodes | Separate management from workspace execution |
| Multi-zone | Central Control Plane | Execution in multiple zones | Proximity to users and distributed capacity |
| HA Control Plane | Multi-node | Independent Execution Pool | Control Plane redundancy and enterprise operations |
04ARCHITECTURE
Architecture
Control Plane and Execution Plane are deliberately not the same.
Intent and Policy stay in the Control Plane; agents carry out management, and the real session runs in the Execution Plane.
USERBrowser ExperienceAuthentication, Catalog, Launch/Resume and session end.
↓
CONTROLWorkspace Control PlanePostgreSQL, Identity, Policy, Scheduling and durable operations.
↓
AGENTAuthenticated Agent PlaneOutbound-first management with defined trust and state.
↓
EXECUTIONWorkspace execution environmentBrowser/Desktop/Application runtime and Remote Session.
| Layer | Component / Protocol | Role | Contract |
|---|---|---|---|
| State Authority | PostgreSQL | Workspace intent, Session lifecycle, Policy, Node/Capacity and durable operations | UI and Agent do not create independent sources of state |
| Control Plane | Go services + Product API | Identity, Authorization, Scheduling, lifecycle and audit | Control Plane ≠ Execution Plane |
| Agent Plane | Outbound-first mTLS agents | Node management, observed state and bounded action execution | Agent authority passes through the Product API/RBAC |
| Linux Streaming | KasmVNC | Browser/Desktop/Application workspace streaming | Protected execution stays on the Execution Plane |
| Remote Access | Apache Guacamole ecosystem | RDP / VNC / SSH from the browser | Remote protocols sit behind the same Identity/Policy surface |
TECH
Install & Runtime Contract. Workspace is not installed from a source checkout; the release artifact, preflight and resume boundary are part of the Product Contract itself.
| Boundary | Mechanism | Technical contract |
|---|---|---|
| Release artifact | MANIFEST.json + SHA256SUMS | API, Controller, Edge, CLI, migration and runtime inputs are delivered as a deterministic bundle. |
| Preflight 1 | Read-only boundary preflight | The release cache, host and installation boundaries are checked before any mutation. |
| Release authority | Exact cached artifact | The verified artifact, with an identity bound to the commit/manifest, is published into the installer-owned cache; unsafe hard links and permissions are rejected. |
| Preflight 2 | Cached-artifact preflight | The same exact artifact is checked again before convergence so source and runtime paths do not diverge. |
| Host exposure | Loopback TLS edge | PostgreSQL and the Control API are not host-published; the canonical product endpoint stays on the bounded TLS edge. |
| Diagnosis / resume | Doctor + status-json | resume_required and last_safe_resume_point are reported from the durable owner boundary, not from browser guesswork. |
| Execution | Docker Engine first · Kubernetes optional | KasmVNC and Guacamole run in the Execution Plane. |
05LIFECYCLE
Lifecycle
A session is more than a launch.
From authentication to Scheduling, Policy enforcement, Resume, Recording and End, everything is part of the user and infrastructure lifecycle.
01Sign inAuthenticate
02ChooseSelect
03SchedulingSchedule
04StartLaunch
05Apply PolicyEnforce
06ContinueResume
07MonitorObserve
08FinishEnd
06WORKSPACE PROFILES
Workspace profiles
The access type changes; the product experience stays the same.
Users enter from a single Catalog, and differences in the execution environment are managed behind the same process.
Browser WorkspaceISOLATED BROWSER
A controlled Linux browser for accessing web applications.
- Session separated from the endpoint
- Policy on File/Clipboard/Network
- Ephemeral lifecycle
Linux Desktop / AppGUI WORKSPACE
A Linux desktop or application delivered through streaming.
- Containerized execution
- Catalog-based launch
- Capacity-aware scheduling
Remote SystemsRDP / VNC / SSH
Secure connection to existing systems from the browser.
- No local client dependency
- Central access policy
- Unified session audit
Single-nodeSTART SMALL
Control and Execution on one host.
- Simplest installation
- The same full UX
- A growth path without changing the user model
DistributedSCALE OUT
Independent execution nodes under one Control Plane.
- Capacity pool
- Node health
- Workload placement
Multi-zoneLOCATION AWARE
Execution closer to the user or resource.
- Location-aware scheduling
- Failure-domain separation
- Central policy
07ACTION & WORKFLOW CONTRACT
Session and recovery flow
A session is not a momentary request; both the operation and the observed runtime are tracked.
Launch, Stop, Restart and Recovery go from the Product API to Operation/Outbox, and session state is observed separately from request state.
01RequestREQUESTED
02AdmissionADMITTED
03RuntimeRUNNING
04RepairRECONCILING
05SuccessSUCCEEDED
06FailureFAILED / CANCELLED
SCHEDULER BRANCH
Placement based on Policy and Capacity
A session is created only on an authorized, ready node.
SESSION REQUEST
↓
POLICY +
CAPACITY
CAPACITY
↓
NODE A
NODE B
NODE C
Scheduler → agent admit → runtime launch → observed ready
No capacity → admission blocked, not random placement.
ACCESS SPLIT
Linux Workspace or Remote Protocol
Identity/Policy is shared; the Execution Path differs.
AUTHENTICATED USER
↓
RESOURCE
POLICY
POLICY
↓
KasmVNC
LINUX
LINUX
↙ ↘
GUACAMOLE
RDP/VNC/SSH
RDP/VNC/SSH
One Identity/Policy surface · two protocol runtimes
KasmVNC and Guacamole are two runtime paths under one Control Plane.
RECOVERY FORK
Recover Runtime or Cleanup
The failure class determines whether repair or cleanup is performed.
FAILED / STALE SESSION
↓
CLASSIFY
↓
RECOVER
RUNTIME
RUNTIME
↙ ↘
RECOVER
CLEANUP
CLEANUP
↓
OBSERVE + CONVERGE
Unknown runtime state is resolved through Agent read-back before any retry.
Launch Workspace
The session is actually created only after admission and scheduling.
01Identity02Policy03Catalog04Capacity05Scheduler06Session Ready
Failure / RecoveryThe UI does not guess the session outcome from an accepted operation.
Remote Access
The browser connects to the protocol runtime without the endpoint becoming the place of trust.
01User Login02Resource Scope03Policy04Guacamole Route05RDP/VNC/SSH06Session Observe
Failure / RecoveryA policy failure or target failure stops the access path before session attach.
Session Restart
A restart is linked to a traceable successor session.
01Source Session02Restart Admit03Stop Boundary04Successor Create05Health06Attach
Failure / RecoverySource and successor correlation is preserved; an incomplete restart is not reported as success.
Runtime Recovery
Recovery is not the same as an ordinary restart.
01Failure Detect02Classify03Recover Runtime04Agent Action05Observe06Converge
Failure / RecoveryThe recovery attempt and retry count remain in history.
Node Drain / Remove
Session infrastructure changes without orphaning workloads.
01Node Health02Capacity Gate03Stop Placement04Drain Sessions05Remove06Reschedule Verify
Failure / RecoveryA node with active sessions is never silently removed.
ADDITIONAL OPERATIONAL FLOWS
Additional operational flows
Policy and Capacity are also part of the session runtime, not peripheral settings.
Policy / DLP Change
A policy change remains traceable from the authority to its enforcement on the session.
01Policy Intent02Scope / RBAC03Conflict Check04Persist Policy05Agent Propagate06Session Apply07Observe
Failure / RecoveryPartial policy application goes to Reconcile; the session must not continue with a silent bypass and no evidence.
Add Execution Node
New capacity enters the pool only after Trust, Health and Scheduling eligibility.
01Node Identity02Preflight03Agent mTLS04Register05Capacity Observe06Scheduling Eligible07Placement Verify
Failure / RecoveryAn unhealthy node, or one without a valid Agent identity, does not become eligible for placement.
| Action / Flow | Admission / Preconditions | Execution / Lock | Success Criterion | Failure / Recovery |
|---|---|---|---|---|
| Launch Workspace | Actor/Project permission, Catalog entry, Policy and Capacity must all allow it | Idempotency-Key → durable Operation/Outbox → scheduler/Agent | A Session ID and observed session/runtime state are returned for the same Workspace | A failure can create a retry/recovery event; the UI does not guess session state from the Operation |
| Stop Session | Existing session and valid permission | A separate stop Operation goes to the Agent/runtime | The session is no longer serving/running and the Operation becomes terminal | Cancellable before lease; after a side effect the outcome must be reconciled from the runtime |
| Restart Session | Valid source session and restart allowed | The Operation is linked to the restart attempt and the successor session | The successor session is observed and usable | Source/successor correlation is preserved; a failure does not report the previous session as a new success |
| Recover Runtime | Session has a failure/recovery condition | Explicit RECOVER_RUNTIME action; a generic restart does not replace recovery semantics | The runtime is observed-ready again and the session leaves the recovery state | The recovery attempt and the time of the last retry remain in history |
| Recover Cleanup | Provable stale/partial runtime cleanup | Explicit RECOVER_CLEANUP action on the same session | Half-finished resources are cleaned up and the authority converges with the runtime | Cleanup without evidence is not turned into a new session or a success |
| Node Capacity Lifecycle | Node/Execution Plane health and capacity are checked before Add/Drain/Remove | Scheduling is separate from, but coordinated with, the node lifecycle | Retained sessions are healthy and placement/capacity is read from observed state | Drain/Remove must not silently orphan an active session; reconciliation is the return path |
FLOW
Cancellation is possible only at the early safe boundary: the Operation is in REQUESTED/ADMITTED, has no lease owner and has not crossed the side-effect boundary. History keeps Launch/Stop/Restart/Recover, the retry count and the latest recovery.
08OPERATIONS CATALOG
Operations catalog
Workspace operations revolve around the User Journey and the Infrastructure Journey.
The user sees the session; at the same time the operator manages capacity, nodes, Policy and Audit.
Separate the workspace from the endpoint; keep the user experience simple.
4SO Workspace turns secure access from scattered connections into one manageable product.