---
myst:
  html_meta:
    "description lang=en": "Use Kasm Workspaces to separate client device web browsers from potential cyber attacks and allow access to on premise resouces by leveraging ephemeral Workspace sessions streaming a remote web browser."
    "keywords": "Kasm, Browser, Isolation, Zero Trust, Zero-Trust"
    "property=og:locale": "en_US"
---
```{title} Browser Isolation
```

# Browser Isolation

```{include} browser_isolation/browser_isolation_video.md
```

One of the biggest security risks to organizations is direct internet access to the endpoint. Employees typically
need access to the internet to do their jobs, but the proliferation of viruses, malware and phishing attacks pose a
significant risk. A single mis-click and the organizations infrastructure can be exposed to viruses and ransomware.

Browser Isolation categorically removes this risk, by shifting the paradigm of how this internet is accessed. Users can
still access the internet from their endpoint systems, but instead use a remote, containerized browser that is accessed
directly from their native browser.

```{figure} /images/browser_isolation/kasm_browser.png
:align: center
:width: 80%

**The Kasm Chrome container being accessed from Internet Explorer**
```

Kasm Workspaces provides browser isolation by running a remote, containerized browser that is
rendered inside the user's local browser. This allows organizations to cut off direct internet access to the endpoint
and tightly control what goes in and out of the network. This is the ultimate protection from viruses, ransomware, and
other types of malware. It also enhances data loss prevention programs by allowing administrative control items uploaded
, downloaded and copied to the Kasm.

## Seamless Browsing

To make browser isolation feel more seamless to the end users, Kasm Workspaces provides additional interfaces that make
regular tasks feel the same. For example, when the user attempts to navigate to a website using their local browser,
the request is intercepted, A Kasm remote browser is shown, and the remote browser navigates to original website requested.

In similar fashion if a user clicks a link in local document or email, the local browser is launched, loads the Kasm
remote browser, and navigates to the link that was in the document.

## /go URL

Kasm Workspaces exposes a **/go** url that is used to launch or resume as Default Kasm for a user. **kasm_url** can
also be passed as a query argument to this URL and exposed as a variable when defining
[Docker Exec Config](../guide/workspaces.md#docker-exec-config) to launch a new browser tab.

```{code-block} bash
:caption: '**/go url examples**'

https://<kasm-server>/#/go?kasm_url=<destination-url>
https://kasm.company.local/#/go?kasm_url=wikipedia.com
```

```{note}
The Default Kasm can be configured as a [Group Setting](../guide/groups.md#group-settings)  or as a
[User Setting](../guide/users.md#user-settings)
```

## Auto Login

Kasm offers a group and user setting to automatically launch users into a Kasm after login. The user will have the default
Kasm that is configured on either a group or user setting. This is similar to the Go URL but it does not require the user to
explicitly go to the /go URL. It pushes them directly after login. This is useful when users want to be abstracted from the
image creation and dashboard interface.

The User attribute will override the group setting therefore if some users want to still be pushed to the user dashboard after login they may set
the auto login to false.

```{figure} /images/browser_isolation/auto_login_group.jpg
:align: center
:width: 80%

**Use the group setting auto_login_to_kasm**
```

```{figure} /images/browser_isolation/user_auto_login.jpg
:align: center
:width: 80%

**Or Use the User setting on an individual basis**
```

### Workflow

Seamless browsing works by intercepting the user's original request and sending the client a redirect to Kasm Workspaces
with the original request URL encoded in the **kasm_url** parameter. The client's browser then navigates to Kasm Workspaces
and the isolated browser running inside the Kasm sandbox then navigates to the originally requested URL.

```{figure} /images/browser_isolation/proxy_redirect.png
:align: center
:width: 80%

**Proxy Redirection Workflow**
```

In order to do this redirection an explicit or implicit forward proxy is needed. Most large organizations will have a
forward poxy. In order to do redirection with URL encoding of the original request, the proxy must be capable of
configuring custom rules. We have included configuration examples for [](guide/browser_isolation/f5.md#F5) ,
[](guide/browser_isolation/blue_coat.md#BlueCoat) and [](guide/browser_isolation/palo_alto.md#Palo-Alto) vendors.

## Forward Proxy

An explicit forward proxy is one that is explicitly configured in the browser or operating system. Most enterprise
forward proxies will allow you to create a policy that will properly redirect users request to Kasm. The system needs to
redirect, using HTTPS status code 302, to <https://kasm.company.local/#/go>?kasm_url=ORIGINAL_URL where
kasm.company.local is the hostname of your Kasm installation and ORIGINAL_URL is the user's originally requested URL.
This URL needs to be URL encoded. The following sections cover different forward proxy implementations. If your
organization already has a compatible proxy in place, then creating a new policy to redirect is all that is needed.
If a proxy is not already in place, clients will need the organizations root CA cert trusted by their browser and/or
Operating system. If the proxy is an explicit proxy, the browser and/or operating system will need proxy settings
configured.

```{include} /guide/browser_isolation/blue_coat.md
```

```{include} /guide/browser_isolation/f5.md
```

```{include} /guide/browser_isolation/palo_alto.md
```

```{include} /guide/browser_isolation/squid.md
```