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 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 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. 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. 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 three tags for each version of a Kasm Workspace image. One tag is the version, such as 'kasmweb/ubuntu-jammy-desktop:1.18.0', where 1.18.0 is the version. This version only tag is a point in time release that is never updated. The second tag has '-rolling-daily' on the end, such as 'kasmweb/ubuntu-jammy-desktop:1.18.0-rolling-daily', these rolling daily tagged images are updated daily. The third tag has '-rolling-weekly' on the end, these rolling weekly tagged images are updated weekly. 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 custom 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 CI/CD 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, you must use an external identity provider for authentication. Kasm supports LDAP, SAML, and 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.