Kasm Workspaces Security
This reference is an official hardening checklist for Kasm. Per DISA guidance, you may use the vendor-provided hardening baseline when applicable STIGs are not available.
Global settings
The following tables cover settings to check, along with their default value and hardened value. After you harden the global settings, restart all Kasm services.
Authentication
| Name | Severity | Default Setting | Recommended Setting | Rationale |
|---|---|---|---|---|
| Enable Kasm Authorization | Critical | True | True | This applies to authentication of HTTPS requests 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. 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 aligns with STIG guidance. |
| Notice Message | Low | Empty | The banner required by the organization. | DoD STIGs and other guidance usually require a login banner. |
| Session Lifetime | Medium | 288000 | 3600 | A user's token refreshes every 5 minutes during active use. An idle user is logged off after the idle session timeout, which is a group setting. When the user ungracefully terminates the browser, the token is not refreshed and the user is not auto logged off. This setting ensures the token is valid for only 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 added to the All Users group automatically, which gives all users access to all Workspaces. This may suit small deployments, but in an enterprise environment, add Workspaces to groups manually so an administrator grants access explicitly. |
Logging
By default, Kasm forwards all logs to managers, which log them to the database. Database logs are fine for small deployments, but they do not meet enterprise logging, auditing, and alerting requirements. Kasm supports forwarding logs to Splunk using the Splunk native HEC protocol, configured in the global settings. Restart each web app role server's services after changing the global log settings. Alternatively, use a log forwarding agent on each server, such as Logstash or the Splunk Forwarder. Kasm stores all logs at /opt/kasm/current/log in both raw and JSON format. Forward only the JSON-formatted files, since Kasm rotates logs and you only need to forward the current log file for each series.
With centralized logging configured, the following settings reduce the burden on the database.
| Name | Default Setting | Recommended Setting | Rationale |
|---|---|---|---|
| Debug Log Retention | 4 | 0 | Large deployments produce large amounts of debug logs that overwhelm the database. With log forwarding configured, drop debug logs from database logging. |
| Log Host | Hostname or IP address of the Splunk HEC receiver. | Configure when using Kasm's built-in support for Splunk HEC log forwarding. | |
| Log Port | The port number used by the Splunk HEC receiver. | Configure when using Kasm's built-in support for Splunk HEC log forwarding. | |
| Log Protocol | internal | splunk | Configure when using Kasm's built-in support for Splunk HEC log forwarding. |
| Log Retention | 7 | 5 | This controls the number of days of logs kept in the Kasm database. With log forwarding configured, reduce this. Larger deployments should use a lower value. A value of 0 disables storing logs in the database. |
Manager
| Name | Severity | Default Setting | Recommended Setting | Rationale |
|---|---|---|---|---|
| Update Check | Medium | True | False | Kasm periodically checks for updates with an API call to a public endpoint managed by Kasm. The API contains only the installation ID. Disable this for offline or internet-restricted environments. |
Group settings
A user can belong to multiple groups. Group settings are aggregated across all groups a user belongs to. Most settings can be applied only once, in which case the group with the lowest priority value takes precedence. View a user's effective groups and group settings in the Users panel of the Admin dashboard. Use the All Users group to define the most restrictive set of group settings. To override with less restrictive settings, define the same setting on a group with a lower priority.
The following table defines the recommended settings for the All Users group. It includes only the settings required under the general Application Security and Development Security STIGs. Set other values based on your organization's requirements, such as whether to allow audio in and out, clipboard in and out, uploads, and downloads. Some settings, such as password_expires, apply only to local user accounts and are not shown below. To meet STIG requirements, use an external authentication provider. See the authentication section for details.
| Name | Recommended Setting | Rationale |
|---|---|---|
| idle_disconnect | 20 | The user is logged out after this many minutes of no interaction. |
| shared_session_full_control | False | Allows users to share their session with other users and grant 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:[[release]], where [[release]] is the version. This version-only tag is a point-in-time release that is never updated. The second tag ends with -rolling-daily, such as kasmweb/ubuntu-jammy-desktop:[[release]]-rolling-daily, and is updated daily. The third tag ends with -rolling-weekly and is updated weekly. When the Kasm Workspace definitions point to a Docker registry, Kasm pulls updates automatically and uses them for new sessions. By default, Kasm uses the non-rolling tagged images, which ensures reliability for production environments. For security, rolling tags are recommended. For production, test image updates before updating.
Many use cases require custom images based on one of the core Docker images. Base your images on a rolling tagged image. Create a staging Workspace to test new image updates before updating production Workspaces. Use automated CI/CD pipelines to build the custom images and automatically scan the resulting images.
Authentication
To meet the general requirements under the Application Security and Development Security STIGs, use an external identity provider for authentication. Kasm supports LDAP, SAML, and OIDC authentication providers.
The default local accounts remain defined in Kasm. Delete user@kasm.local in the Users table. Keeping the default admin@kasm.local allows emergency access when the external authentication provider is down. Kasm has built-in MFA for local accounts, and you can establish alerts for login events for this user with a central logging solution such as Splunk. Alternatively, delete admin@kasm.local and create a different local account with a more obscure name that is not a known default username. These controls help mitigate the risk of leaving the default local account on the system. Check with your security team for guidance.