Remote Browser Isolation (RBI)
Remote Browser Isolation (RBI) is a security approach that separates web browsing from the user’s endpoint. The browser runs in a remote, isolated environment, and only a visual representation of the session reaches the local device. Because no web content, scripts, or downloads ever execute on the endpoint, an entire class of browser-borne threats — malware, drive-by downloads, malicious scripts — is contained on the cluster.
In Cloud Manager, RBI is delivered through Kubernetes Models: create a model from one of the built-in browser models — Chrome RBI, Chrome noVNC, or Chrome RDC — and expose it through an Access Profile. Each user session then runs a browser inside a Linux container (a pod) on the cluster, and only the streamed output reaches the user. RBI has no separate navigation node in Cloud Manager; you work with it through the Kubernetes credential, the model, and the model’s Pods tab.
To create one of these models and manage its pods, see Kubernetes Models.
How Isolation Works
When a user opens an isolated session through an access profile, Cloud Manager deploys a pod on demand that runs the browser entirely on the cluster. Only a remote representation of that browser — a streamed image painted into the user’s own browser — reaches the endpoint; the user sees and controls the session while no web content, scripts, or downloads execute on the local device.
The connection is established outbound from the pod, which is the security boundary of the design:
- The user never connects directly to the pod. Access is always brokered through the Thinfinity Workspace Gateway.
- A component inside the pod opens an outbound connection to the Gateway and registers there. The pod exposes no inbound ports, so no Ingress, public IP, or per-pod firewall rule is required for users to reach it.
- When the user connects, the broker routes the session to the registered pod and streams the browser to the endpoint.
When you open a pod’s log from the Pods tab, the Container selector lets you choose which of the pod’s containers to view — the browser workload, or the component that connects the pod to the Gateway.
Built-in Models
Cloud Manager ships three built-in Kubernetes models, each pre-configured with its own pod definition so you can create a working model without authoring a manifest. All three run the browser remotely in a container; they differ in how the session is delivered and which features it supports.
- Chrome RBI — the dedicated browser-isolation model. It streams an isolated Chrome browser and supports the full set of session features (clipboard, audio, microphone, file transfer, quality control, and high DPI). It can also retain a user’s Chrome profile — passwords, extensions, themes, cookies, history, and settings — across sessions when the cluster and model are configured for it.
Chrome profile persistence is configured at the cluster and manifest level, not through a profile toggle. See Chrome Profile Persistence.
- Chrome noVNC — the lightest model. It streams an isolated browser through a standard viewer, with text-only clipboard and none of the advanced session features. Use it when all you need is to show an isolated browser.
- Chrome RDC — a full Linux desktop running Chrome, delivered over Remote Desktop Connection (RDC) access. It is broader than browser isolation and the richest in capabilities, suited to use cases that need a full desktop rather than a single browser.
| Chrome RBI | Chrome noVNC | Chrome RDC | |
|---|---|---|---|
| Delivers | Isolated Chrome browser | Isolated browser (lightweight) | Full Linux desktop with Chrome |
| Clipboard | Text | Text | Text and files |
| File transfer | Upload only | No | Yes |
| Audio / microphone | Yes | No | Yes |
| Quality control | Yes (Low/Optimum/High) | No | Yes |
| High DPI | Yes | No | Yes |
| Persistent profile | Yes | No | — (desktop session) |
| Best for | Browser isolation with full session controls | A simple isolated browser | Full-desktop sessions beyond a single browser |
Use Chrome RBI when your goal is browser isolation — it is purpose-built for it and supports the full set of session features below. Choose Chrome noVNC for a minimal isolated browser, or Chrome RDC when users need a full desktop.
RBI Session Features
An RBI Access Profile created from a Chrome RBI model exposes its session controls under Display and Resources in the profile editor. All are off by default, so each is opt-in.
| Control | Section | Description |
|---|---|---|
| Quality | Display | Image quality of the stream — Low, Optimum, or High — trading visual fidelity against bandwidth. |
| High DPI | Display | Raises rendering density for sharp text and UI on high-resolution displays, up to 4K. |
| Audio | Resources | Streams the isolated browser’s audio to the endpoint, and can carry the user’s microphone into the session. |
| Clipboard Sync | Resources | Synchronizes clipboard text between the isolated browser and the endpoint. Text only — images and other formats are not carried. |
| File Uploads | Resources | Lets the user upload files from their local device into the isolated session. |
These controls apply to the Chrome RBI model. Chrome noVNC supports only text clipboard; Chrome RDC supports a broader set, including file-capable clipboard and disk redirection — see the comparison above.
RBI Session Lifecycle
- Pod creation — The user connects through an Access Profile that targets the Kubernetes Model. The broker deploys a pod on demand from the model’s definition, starting the browser stack.
- Outbound registration — A component in the pod opens an outbound connection to the Thinfinity Workspace Gateway and registers; the broker then sends it routing configuration and credentials. The pod exposes no inbound ports.
- Client connection — The user reaches the session only through the Gateway, and their browser displays the streamed, isolated browser.
- Active session — The user interacts with the browser through the stream. Clipboard, audio, and file-transfer channels are active according to the profile configuration. When Chrome profile persistence is configured, the user’s Chrome data is retained for the next session.
- Disconnect and idle cleanup — When the session ends, the pod goes idle. After the model’s Destroy after idle period elapses, Cloud Manager removes the pod and its resources.
For how pods are created, monitored, and removed in the interface, see Kubernetes Models.
See Also
- Kubernetes Models — Create a browser-isolation model and manage its pods.
- Kubernetes Credentials — Connect Cloud Manager to the cluster that runs the pods.
- Deploy Remote Browser Isolation — A Quick Start that stands up Chrome RBI end to end.
- Choosing a Compute Path — Where Kubernetes Models fit among the three compute paths.