Remote Browser Isolation

EasyAccess RBI: the browser runs somewhere else

Web content is code, and code you did not write should not execute on a device you do not control. EasyAccess RBI runs the browser in a disposable container inside your own cluster and sends the user a video stream. Nothing from the web ever reaches the endpoint.

Endpoint
No agent, any WebRTC browser
Latency
Under 300 ms streaming
Isolation
One container per session
The challenge

Not every device can be trusted, and not every device can take an agent

Contractors, auditors, agency staff and people using their own laptops all need to reach something of yours. Managing those devices is often not an option, legally, practically or politically.

The usual answers are unsatisfying. Issuing corporate hardware to a three-week contractor is expensive and slow. Virtual desktops are heavy to run and worse to use. Letting an unmanaged machine onto the network, even through a tunnel, means trusting a device whose patch level and malware status you cannot see.

Browser isolation sidesteps the question. If the browser never runs on the device, the state of that device stops being the thing that protects you.

Unmanaged endpoints

Personal and third-party machines with no agent, no posture signal and no way to enforce patching.

Risky destinations

Research, threat intelligence and supplier portals that staff genuinely need to open, on sites nobody is willing to vouch for.

Data that should not be copied

Applications a user must read but must not download, print or paste out of into somewhere else.

Access that must end cleanly

When an engagement finishes, nothing should be left behind on a machine you will never see again.

How it works

Pixels cross the boundary, code does not

The browser, its memory and anything it downloads all stay inside your cluster. The endpoint receives a video stream and sends back keyboard and mouse input.

How EasyAccess RBI isolates a browser session The user's device exchanges a WebRTC video stream and input events with a disposable browser container running inside the customer's Kubernetes cluster. Only that container connects onward to the target web application. User device Unmanaged laptop Any WebRTC browser Your perimeter video input Your Kubernetes cluster Portal SSO, catalogue Browser pod disposable, one per session Destroyed when the session ends HTTPS egress-filtered Target Internal app or the open web

A downloaded file, a malicious script or a drive-by exploit lands inside the container, which is thrown away minutes later.

Capabilities

Isolation, and the controls around it

Isolation by construction

Each session is its own container with its own filesystem and memory, discarded when the session ends. There is no shared browser profile to poison and no persistence between users.

  • One disposable container per session
  • Kubernetes network policy restricts pod egress
  • Sessions are never exposed directly: the portal proxies them
  • Session tokens are never returned in API responses

Kiosk lockdown

The remote browser is not a general-purpose browser. It opens where policy says it opens and offers the user no way out of that.

  • Fullscreen kiosk mode, no address bar
  • Developer tools and context menu disabled
  • Clipboard operations disabled by default
  • File transfer disabled by default
  • Domain blocklists and a locked target URL

Who gets what

Users sign in through your identity provider and see only the applications their roles and groups allow. Administrators work in a separate portal.

  • OIDC and OAuth 2.0 single sign-on
  • Application catalogue filtered by role and group
  • Separate administration portal
  • Complete audit trail of user and admin actions

Sessions that end

Timeouts are enforced by the platform rather than left to the user closing a tab, and an administrator can terminate anyone's session immediately.

  • Configurable session and inactivity timeouts
  • Background worker reclaims abandoned sessions
  • Live view of every running session
  • Forced termination of any user's session
Architecture

What it is made of

A single Go binary with both portals compiled in, orchestrating browser pods through the Kubernetes API and relaying their media itself.

Portal and orchestrator
Go, with the user portal and administration portal embedded in the binary; PostgreSQL for applications, users, sessions and audit records
Session orchestration
Kubernetes API, one pod per session with configurable CPU and memory limits, cleaned up by a background worker
Streaming
WebRTC over DTLS/SRTP with a built-in selective forwarding unit and a built-in TURN server for NAT traversal; WebSocket signalling
Browser container
Chromium in kiosk mode with an in-house capture stack built on GStreamer and X11, delivering video, audio, cursor and input
Default stream
1920×1080 at 30 frames per second, adjustable per deployment
Identity
OIDC / OAuth 2.0 against your existing provider, with users synchronised on sign-in; JWT session cookies
Network posture
Network policies restrict pod egress to permitted internal ranges and ports; the portal reaches only the database, the Kubernetes API and your identity provider
Observability
Prometheus metrics endpoint and health probes on the portal and on session pods
Deployment

Runs in your cluster

EasyAccess RBI is delivered as a container image and a set of manifests. There is no hosted component and no browsing data leaves your infrastructure.

Kubernetes

Manifests for namespace, configuration, deployment, RBAC, ingress, network policy and a TURN server, ready to adapt to your cluster conventions.

k3s

A lighter path for smaller or edge deployments, with PostgreSQL and the portal running in the same cluster.

Docker

A multi-stage build producing a small non-root image, with Docker Compose for evaluation and development environments.

Give access without giving trust

Tell us which devices you cannot manage and which applications they need, and we will show you EasyAccess RBI against that case.