Docker
Kasm Workspaces requires Docker and will install Docker if it is not already installed on the system. Organizations should consider this before installing Kasm, especially in offline environments. The standard Ubuntu 20.04 LTS and newer APT repository already has a version of Docker that is new enough to be used with Kasm Workspaces. For offline environments, we recommend that you install Docker from the APT repository prior to installing Kasm. This will ensure the offline system will be able to patch docker from your organization’s internal APT repository.
sudo apt-get install docker.io
To fully pass Docker STIGs, you must install Kasm on a non-default (443) port using the -L option, in addition to other options required for your specific deployment.
sudo bash kasm_release/install.sh -L 8443
Kasm Technologies has created open-source hardening scripts. The project includes one script that hardens the Docker daemon configuration and the other that hardens the Docker runtime of Kasm. Both scripts are targeting the DISA Docker Enterprise STIG checklist. The scripts also output a list of STIGs with vulnerability IDs and a pass/fail status. This can be used as an artifact for STIG checklists. Follow the instructions provided in the README of the project page.
The following table lists all Docker EE STIGs and CIS Docker CE Benchmarks that are either fixed by the Kasm hardening scripts or that pass by default assuming the system was clean prior to installing Kasm. This has been tested on clean installs of Ubuntu 20.04LTS.
Vuln ID |
CIS ID |
|---|---|
V-235812 |
2.16, 5.21 |
V-235816 |
2.18, 5.25 |
V-235851 |
3.1 |
V-235861 |
3.11 |
V-235864 |
3.14 |
V-235865 |
3.15 |
V-235866 |
3.16 |
V-235867 |
3.17 |
V-235868 |
3.18 |
V-235869 |
3.19 |
V-235870 |
3.20 |
V-235853 |
3.3 |
V-235855 |
3.5 |
V-235859 |
3.9 |
V-235809 |
5.17 |
V-235817 |
5.30 |
V-235818 |
5.31 |
V-235805 |
5.9 |
V-235807 |
5.11 |
V-235791 |
2.15 |
V-235790 |
2.5 |
V-235844 |
2.7 |
V-235815 |
2.9, 5.24 |
V-235830 |
4.1 |
V-235827 |
4.6, 5.26 |
V-235799 |
5.1 |
V-235806 |
5.10 |
V-235820 |
5.13 |
V-235784 |
5.15 |
V-235785 |
5.16 |
V-235810 |
5.19 |
V-235811 |
5.20 |
V-235828 |
5.28 |
V-235801 |
5.3 |
V-235802 |
5.4 |
V-235837 |
5.8 |
V-235831 |
|
V-235804 |
|
2.6 |
|
V-235800 |
5.2 |
V-235783 |
5.5 |
V-235803 |
5.6 |
V-235813 |
5.22 |
V-235792 |
2.17 |
V-235814 |
5.23 |
2.10 |
|
2.3 |
|
7.1 |
The following list of STIGs/CIS checks pass after running the Kasm hardening script or pass by default, however, they have additional notes that need to be considered per your specific deployment and security requirements.
Vuln ID |
CIS ID |
Explanation |
|---|---|---|
V-235786 |
5.1 |
The documented fix for this STIG is not compatible with all versions of Docker, therefore, it was removed from our hardening script. Clients will need to manually add this setting to the daemon.json file, if the version of Docker that is installed supports this feature. |
V-235808 |
5.12 |
All Kasm service containers pass this check after the apply_kasm_stigs.sh script is ran on all Kasm systems. However, user Workspace containers are not set to read only. This is not practical on a desktop. We believe this check is intended and practical for the 99% of the use cases of docker, however, it does not apply nor is it intended for Desktop containers. If the authorizing official is not satisfied with this explanation, then there are two potential courses of action: 1) Use full stack VMs for user desktops (now supported by Kasm). Since a full stack VM would also not use a read-only file system, nor is there a STIG that requires this for a desktop operating system. We feel this solution provides no security benefit as related to this particular STIG, but it does bypass the STIG since user desktops would use VMs instead of containers. 2) An exception to policy. |
V-235860 |
3.10 |
This check is applied by the apply_kasm_stigs.sh script, however, it is missing from the script output. Perform this command to validate, ‘ls -l /etc/docker/certs’ |
V-235862 |
3.12 |
This check is applied by the apply_kasm_stigs.sh script, however, it is missing from the script output. Perform this command to validate, ‘ls -l /etc/docker/certs’ |
V-235863 |
3.13 |
This check is applied by the apply_kasm_stigs.sh script, however, it is missing from the script output. Perform this command to validate, ‘ls -l /etc/docker/certs’ |
V-235833 |
See section on enterprise logging. |
|
2.12 |
See section on enterprise logging. |
|
V-235800 |
5.2 |
This is N/A for Ubuntu systems, which use AppArmor profiles instead. If SELinux is enabled by default in RHEL compatibale Operating Systems (i.e Rocky Linux), it is not disabled by Kasm. Therefore, systems should be compliant by default under normal curcumstances. |
V-235783 |
5.5 |
The apply_docker_stigs.sh script will report if the system passes, but will not alter the system. |
V-235803 |
5.6 |
The apply_docker_stigs.sh script will report if the system passes, but will not alter the system. |
V-235872 |
7.4 |
Kasm Workspaces does not rely on Docker for underlying communications between containers on different nodes. All communications between componets on different nodes is encrypted with TLS. |
1.4 |
Kasm does not add any users to the docker group, therefore, this check should pass unless you have modified the system. |
|
2.1 |
Kasm does not use the default docker network for service containers or user containers. DO NOT implement the CIS recommended fix of disabling inter-container traffic at the dockerd level, this would break Kasm. If you are using the host only for Kasm, then this check is passed by default as the default docker network would not be used. Otherwise, you need to disable inter-contaienr communications only for the default network. |
|
2.8 |
By default and with the STIG scripts applied, all containers run as an explicit user that is explicitly mapped to a known user on the host. The audit check says to look for containers running as a user that maps to root on the host. Again, by default and with STIG scripts applied, this would not be the case. It is still possible to configure a Kasm Workspace to run as root, see Check column. |
|
4.2 |
A default installation will use all Kasm maintained images or official vendor maintained images for third party containers such as Redis, NGINX, and Postgres. The admin can define user Workspaces that use a non-Kasm maintained image. See the check column for details. |
|
V-235832 |
This is N/A on the latest version of Docker, as the max-file and max-size options are not supported by the log-drivers required by V-235831 |
Docker Enterprise
Kasm does not require Docker Enterprise and installs Docker CE if it is not already installed. If you decide to use Docker CE, you must then choose whether to apply the CIS Benchmarks for Docker CE, or use the DISA STIGs for Docker EE and mark checks as N/A where they apply only to EE. The STIG checklist refers to Docker Enterprise throughout, however, you must read the checks carefully to determine if they would apply to CE. The table we provide clearly marks which ones we believe only apply to Docker Enterprise, however, you will need to make that determination for yourself.
Enterprise Logging and Audit Rules
Both the DISA STIGs and CIS Benchmarks have you apply various configurations related to logging and audit rules. Some of these settings are at the docker daemon level and some are at the system level. Our guide assumes that your system is hardened and already meets operating system level STIGs which already enforce centralized logging for syslog as well as auditd installation and configuration.
Our hardening script will configure dockerd to forward logs using syslog to 127.0.0.1:25224 over UDP. This allow the host to pass automated checks based on the DISA audit commands, however, this in and of itself is not enough to complete the configuration. You must either configure each host to listen on that port and then forward the logs, or you must change the /etc/docker/daemon.json configuration to forward the logs to another server. Another option would be to configure dockerd to log to a json file, and then use a logging agent to forward the logs to a centralized logging solution. Once the logs are forwarded to a centralized logging solution, you should meet the controls related to alerts, assuming your enterprise logging solution is already configured to provide such alerting.
To meet all STIG and CIS Benchmarks related to auditd rules, ensure the following lines are in /etc/audit/audit.rules:
-w /usr/bin/docker -k docker
-w /var/lib/docker -k docker
-w /etc/docker -k docker
-w /usr/lib/systemd/system/docker.service -k docker
-w /usr/lib/systemd/system/docker.socket -k docker
-w /etc/default/docker -k docker
-w /etc/docker/daemon.json -k docker
-w /usr/bin/docker-containerd -k docker
-w /usr/bin/docker-runc -k docker
Then restart the audit daemon.
service auditd restart
Kasm application logs are covered in the Kasm Workspaces section.
Docker Swarm
Kasm Workspaces does not require or configure Docker Swarm. With a default installation of Kasm and Docker, with our hardening scripts ran, the Docker Swarm checks should be N/A.