---
myst:
  html_meta:
    "description lang=en": "Kasm Workspaces hardening with CIS or STIG benchmarks"
    "keywords": "Kasm, Server, Configuration, STIGs, Security, CIS, DISA, Workspaces, hardening"
    "property=og:locale": "en_US"
---
```{title} Kasm Workspaces
```

# Kasm Workspaces

The following guide is an official hardening checklist for Kasm. Per DISA guidance, you may use the vendor provided hardening baseline guidance when applicable STIGs are not available.

## Global Settings
The following tables cover {doc}`settings</guide/settings>` that should be checked along with their default value and hardened value. After hardening of global settings, all Kasm services should be restarted.

**Authentication**
| Name | Severity | Default Setting | Recommended Setting | Rationale |
|------|----------|-----------------|---------------------|-----------|
| Enable Kasm Authorization | Critical | True | True | This is in reference to authentication of HTTPS requests that are sent to the user's container. Disabling Kasm Authentication would allow unauthenticated access to user container sessions. |
| Kasm Authorization Domain | Low | $request_host$ | The domain name used by users to access the system. | Kasm dynamically uses the domain name in the user request. Using a hard coded domain name is more explicit and removes a potential attack vector. |
| Max Login Attempts | Low | 5 | 3 | This applies only to Kasm Local Accounts. A setting of 3 is more in line with STIG guidance. |
| Notice Message | Low | Empty | Organization required banner. | DoD STIGs and other guidance usually requires a login Banner. |
| Session Lifetime | Medium | 288000 | 3600 | A user's token is refreshed every 5 minutes when actively using the application. If the user is idle, they will automatically be logged off after the idle session timeout, which is a group setting. If the user ungracefully terminates their browser, the token will not get refreshed and they will also not get auto logged off. This setting ensures the token is only good for 1 hour after the last refresh. |

**Images**
| Name | Severity | Default Setting | Recommended Setting | Rationale |
|------|----------|-----------------|---------------------|-----------|
| Add Images to Default Group | High | True | False | New Workspaces are automatically added to the All Users group, essentially giving all users access to all Workspaces. This might make sense for small deployments, however, in an Enterprise grade environment, Workspaces should be manually added to groups ensuring access management is explicitly granted by an administrator. |

**Logging**<br>
By default, Kasm forwards all logs to managers, which then log them to the database. The database logs are fine for small deployments, however, they are not appropriate to meet enterprise grade logging, auditing, and alerting requirements. Kasm supports forwarding logs to Splunk using the Splunk native HEC protocol. This can be configured in the server global settings. A restart of each web app role server services is required after changing the global log settings. The alternative is to use a log forwarding agent on each server, such as logstash or Splunk Forwarder. Kasm stores all logs at `/opt/kasm/current/log` in both raw and json format. It is recommended to forward the json formatted files. Kasm utilizes rotated logs, therefore, it is only necessary to forward the current log file for each log file series.

With centralized logging configured, the following settings can be used, which will reduce burden on the database.

| Name | Default Setting | Recommended Setting | Rationale |
|------|-----------------|---------------------|-----------|
| Debug Log Retention | 4 | 0 | Large deployments will produce large amounts of debug logs that will overwhelm the database. With log forwarding configured, debug logs can be dropped from database logging. |
| Log Host | | Hostname or IP address of Splunk HEC receiver | Configure if using Kasm's built in support for Splunk HEC log forwarding. |
| Log Port | | The port number used by the Splunk HEC receiver | Configure if using Kasm's built in support for Splunk HEC log forwarding. |
| Log Protocol | internal | splunk | Configure if using Kasm's built in support for Splunk HEC log forwarding. |
| Log Retention | 7 | 5 | This controls the number of days worth of logs to keep in the Kasm database. With log forwarding configured, this can be reduced. Larger deployments should use a lower value. A value of 0 can be used to completely disable storing logs in the database. |

**Manager**
| Name | Severity | Default Setting | Recommended Setting | Rationale |
|------|----------|-----------------|---------------------|-----------|
| Update Check | Medium | True | False | Kasm periodically checks for updates and makes an API call to a public endpoint managed by Kasm. The API contains only the installation ID. For offline or internet restricted environments, this should be disabled. |

## Group Settings
A user can belong to multiple groups. {doc}`Group Settings</guide/groups/group_settings>` are aggregated for all groups a user belongs to. Most settings can only be applied once, in which case the Group with the lowest priority value takes precedent. You can view a user's effective groups and group settings by viewing a user in the Users panel in the Admin dashboard. We recommend using the All Users group to define the most restrictive set of group settings. To override with less restrictive group settings, merely define the same setting on a group with a lower priority. 

The following table defines the recommended settings and values to be placed on the **All Users** group. This table only includes settings we believe are required under the general [Application Security and Development Security STIGs](https://www.stigviewer.com/stig/application_security_and_development/). Other values should also be set based on your organizations requirements, such as whether to allow audio in and out, clipboard in and out, uploads and downloads, and other settings. Some settings, such as password_expires, only apply to local user accounts and are not shown in the below table. To meet STIG requirements, an external authentication provider must be used, see the Authentication section for more details.

| Name | Recommended Setting | Rationale |
|------|---------------------|-----------|
| idle_disconnect | 20 | The user will be logged out after this many minutes of no interaction. |
| shared_session_full_control | False | Allows users to share their session with other users and provide full control of the desktop. |

## Workspace Images
Kasm maintains two tags for each version of a Kasm Workspace image. One tog is the version, such as kasmweb/ubuntu-focal-desktop:{{ release }}, where {{ release }} is the version. This version only tag is a point in time release that is never updated. The second tag has '-rolling' on the end, such as kasmweb/ubuntu-focal-desktop:{{ release }}-rolling. The rolling tagged images are updated daily. If the Kasm Workspace definitions are configured to point to a Docker Registry, Kasm will automatically pull updates and start using them for new sessions. By default, Kasm uses the non-rolling tagged images. The reason for using non-rolling images is to ensure reliability for production environments. For security purposes, the use of rolling tags are recommended, however, for production environments, it is recommended to test image updates prior to updating.

Many use cases will require the need for {doc}`custom images</how_to/building_images>`, which are based on one of our core docker images. We recommend basing your images from a rolling tagged image. Kasm admins can create a "staging" Workspace for testing new image updates, prior to updating production Workspaces. We recommend using automated {doc}`CI/CD</how_to/image_maintenance>` pipelines, to create the custom images, and to perform automated scans of the resulting images. 

## Authentication
In order to meet general requirements under the [Application Security and Development Security STIGs](https://www.stigviewer.com/stig/application_security_and_development/), you must use an external identity provider for authentication. Kasm supports {doc}`LDAP</guide/ldap>`, {doc}`SAML</guide/saml_authentication>`, and {doc}`OIDC</guide/oidc>` for authentication providers.

The default local accounts will still be defined in Kasm. You should delete user@kasm.local in the Users table. Keeping the default admin@kasm.local would allow emergency access, should the external authentication provider be down. Kasm has built in MFA that can be used for local accounts and alerts could be established for login events for this user, with a central logging solution such as Splunk. Additionally, you could delete admin@kasm.local and create a different local account with a more obscure name that is not a known default username. These security controls can help mitigate the risk of leaving the default local account on the system. Check with your security team for guidance.