.. title:: Browser Isolation Browser Isolation ======================== .. include:: browser_isolation/browser_isolation_video.rst :start-line: 2 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 :width: 80% :align: center **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/custom_images.html#docker-exec-config>`_ to launch a new browser tab. .. code-block:: bash :caption: **/go url examples** https:///#/go?kasm_url= https://kasm.company.local/#/go?kasm_url=wikipedia.com .. note:: The Default Kasm can be configured as a `Group Setting <../guide/groups.html#group-settings>`_ or as a `User Setting <../guide/users.html#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 :width: 80% :align: center **Use the group setting auto_login_to_kasm** .. figure:: /images/browser_isolation/user_auto_login.jpg :width: 80% :align: center **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 :width: 80% :align: center **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 `F5`_ , `BlueCoat`_ and `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.rst .. include:: /guide/browser_isolation/f5.rst .. include:: /guide/browser_isolation/palo_alto.rst .. include:: /guide/browser_isolation/squid.rst