In this section, we will cover the Docker Benchmark Security application that you can install and run. The tool will inspect the following components:
- The host configuration
- The Docker daemon configuration
- The Docker daemon configuration files
- Container images and build files
- Container runtime
- Docker security operations
Looks familiar? It should, as these are the same items that we reviewed in the previous section, only built into an application that will do a lot of heavy lifting for you. It will show you what warnings arise with your configurations and provide information on other configuration items and even the items that have passed the test.
We will look at how to run the tool, a live example, and what the output of the process will mean.
Running the tool is simple. It's already been packaged for us inside a Docker container. While you can get the source code and customize the output or manipulate it in some way (say, e-mail the output), the default may be all that you need.
The code is found here: https://github.com/docker/docker-bench-security
To run the tool, we will simply copy and paste the following into our Docker host:
$ docker run -it --net host --pid host --cap-add audit_control -v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock -v /usr/lib/systemd:/usr/lib/systemd -v /etc:/etc --label docker_bench_security docker/docker-bench-security
If you don't already have the image, it will first download the image and then start the process for you. Now that we've seen how easy it is to install and run it, let's take a look at an example on a Docker host to see what it actually does. We will then take a look at the output and take a dive into dissecting it.
There is also an option to clone the Git repository, enter the directory from the git clone command, and run the provided shell script. So, we have multiple options!
Let's take a look at an example and break down each section, as shown in the following command:
# ------------------------------------------------------------------------------ # Docker Bench for Security v1.0.0 # # Docker, Inc. (c) 2015 # # Checks for dozens of common best-practices around deploying Docker containers in production. # Inspired by the CIS Docker 1.6 Benchmark: # https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.6_Benchmark_v1.0.0.pdf # ------------------------------------------------------------------------------ Initializing Sun Jan 17 19:18:56 UTC 2016
Let's take a look at the output of the host configuration runtime:
[INFO] 1 - Host configuration [WARN] 1.1 - Create a separate partition for containers [PASS] 1.2 - Use an updated Linux Kernel [PASS] 1.5 - Remove all non-essential services from the host - Network [PASS] 1.6 - Keep Docker up to date [INFO] * Using 1.9.1 which is current as of 2015-11-09 [INFO] * Check with your operating system vendor for support and security maintenance for docker [INFO] 1.7 - Only allow trusted users to control Docker daemon [INFO] * docker:x:100:docker [WARN] 1.8 - Failed to inspect: auditctl command not found. [INFO] 1.9 - Audit Docker files and directories - /var/lib/docker [INFO] * Directory not found [WARN] 1.10 - Failed to inspect: auditctl command not found. [INFO] 1.11 - Audit Docker files and directories - docker-registry.service [INFO] * File not found [INFO] 1.12 - Audit Docker files and directories - docker.service [INFO] * File not found [WARN] 1.13 - Failed to inspect: auditctl command not found. [INFO] 1.14 - Audit Docker files and directories - /etc/sysconfig/docker [INFO] * File not found [INFO] 1.15 - Audit Docker files and directories - /etc/sysconfig/docker-network [INFO] * File not found [INFO] 1.16 - Audit Docker files and directories - /etc/sysconfig/docker-registry [INFO] * File not found [INFO] 1.17 - Audit Docker files and directories - /etc/sysconfig/docker-storage [INFO] * File not found [INFO] 1.18 - Audit Docker files and directories - /etc/default/docker [INFO] * File not found
Let's take a look at the output for the Docker daemon configuration runtime, as shown in the following command:
[INFO] 2 - Docker Daemon Configuration [PASS] 2.1 - Do not use lxc execution driver [WARN] 2.2 - Restrict network traffic between containers [PASS] 2.3 - Set the logging level [PASS] 2.4 - Allow Docker to make changes to iptables [PASS] 2.5 - Do not use insecure registries [INFO] 2.6 - Setup a local registry mirror [INFO] * No local registry currently configured [WARN] 2.7 - Do not use the aufs storage driver [PASS] 2.8 - Do not bind Docker to another IP/Port or a Unix socket [INFO] 2.9 - Configure TLS authentication for Docker daemon [INFO] * Docker daemon not listening on TCP [INFO] 2.10 - Set default ulimit as appropriate [INFO] * Default ulimit doesn't appear to be set
Let's take a look at the output for the Docker daemon configuration files runtime, as follows:
[INFO] 3 - Docker Daemon Configuration Files [INFO] 3.1 - Verify that docker.service file ownership is set to root:root [INFO] * File not found [INFO] 3.2 - Verify that docker.service file permissions are set to 644 [INFO] * File not found [INFO] 3.3 - Verify that docker-registry.service file ownership is set to root:root [INFO] * File not found [INFO] 3.4 - Verify that docker-registry.service file permissions are set to 644 [INFO] * File not found [INFO] 3.5 - Verify that docker.socket file ownership is set to root:root [INFO] * File not found [INFO] 3.6 - Verify that docker.socket file permissions are set to 644 [INFO] * File not found [INFO] 3.7 - Verify that Docker environment file ownership is set to root:root [INFO] * File not found [INFO] 3.8 - Verify that Docker environment file permissions are set to 644 [INFO] * File not found [INFO] 3.9 - Verify that docker-network environment file ownership is set to root:root [INFO] * File not found [INFO] 3.10 - Verify that docker-network environment file permissions are set to 644 [INFO] * File not found [INFO] 3.11 - Verify that docker-registry environment file ownership is set to root:root [INFO] * File not found [INFO] 3.12 - Verify that docker-registry environment file permissions are set to 644 [INFO] * File not found [INFO] 3.13 - Verify that docker-storage environment file ownership is set to root:root [INFO] * File not found [INFO] 3.14 - Verify that docker-storage environment file permissions are set to 644 [INFO] * File not found [PASS] 3.15 - Verify that /etc/docker directory ownership is set to root:root [PASS] 3.16 - Verify that /etc/docker directory permissions are set to 755 [INFO] 3.17 - Verify that registry certificate file ownership is set to root:root [INFO] * Directory not found [INFO] 3.18 - Verify that registry certificate file permissions are set to 444 [INFO] * Directory not found [INFO] 3.19 - Verify that TLS CA certificate file ownership is set to root:root [INFO] * No TLS CA certificate found [INFO] 3.20 - Verify that TLS CA certificate file permissions are set to 444 [INFO] * No TLS CA certificate found [INFO] 3.21 - Verify that Docker server certificate file ownership is set to root:root [INFO] * No TLS Server certificate found [INFO] 3.22 - Verify that Docker server certificate file permissions are set to 444 [INFO] * No TLS Server certificate found [INFO] 3.23 - Verify that Docker server key file ownership is set to root:root [INFO] * No TLS Key found [INFO] 3.24 - Verify that Docker server key file permissions are set to 400 [INFO] * No TLS Key found [PASS] 3.25 - Verify that Docker socket file ownership is set to root:docker [PASS] 3.26 - Verify that Docker socket file permissions are set to 660
Let's take a look at the output for the container images and build files runtime, as shown in the following command:
[INFO] 4 - Container Images and Build Files [INFO] 4.1 - Create a user for the container [INFO] * No containers running
Let's take a look at the output for the container runtime, as follows:
[INFO] 5 - Container Runtime [INFO] * No containers running, skipping Section 5
Let's take a look at the output for the Docker security operations runtime, as shown in the following command:
[INFO] 6 - Docker Security Operations [INFO] 6.5 - Use a centralized and remote log collection service [INFO] * No containers running [INFO] 6.6 - Avoid image sprawl [INFO] * There are currently: 23 images [WARN] 6.7 - Avoid container sprawl [WARN] * There are currently a total of 51 containers, with only 1 of them currently running
Wow! A lot of output and tons to digest; but what does all this mean? Let's take a look and break down each section.
There are three types of output that we will see, as follows:
[PASS]: These items are solid and good to go. They don't need any attention, but they are good to read to make you feel warm inside. The more of these, the better![INFO]: These are items that you should review and fix if you feel that they are pertinent to your setup and security needs.[WARN]: These are items that need to be fixed. These are the items we don't want to be seeing.
Remember, we had the six main topics that were covered in the scan, as shown in the following:
- The host configuration
- The Docker daemon configuration
- The Docker daemon configuration files
- Container images and build files
- Container runtime
- The Docker security operations
Let's take a look at what we are seeing in each section of the scan. These scan results are from a default Ubuntu Docker host, with no tweaks made to the system at this point. We want to again focus on the [WARN] items in each section. Other warnings may come up when you run yours, but these will be the ones that come up the most, if not for everyone at first.
Let's take a look at the following output for the host configuration runtime output:
[WARN] 1.1 - Create a separate partition for containers
For this one, you will want to map /var/lib/docker to a separate partition.
[WARN] 1.8 - Failed to inspect: auditctl command not found. [WARN] 1.9 - Failed to inspect: auditctl command not found. [WARN] 1.10 - Failed to inspect: auditctl command not found. [WARN] 1.13 - Failed to inspect: auditctl command not found. [WARN] 1.18 - Failed to inspect: auditctl command not found.
Let's take a look at the following output for the Docker daemon configuration output:
[WARN] 2.2 - Restrict network traffic between containers
By default, all the containers running on the same Docker host have access to each other's network traffic. To prevent this, you would need to add the --icc=false flag to the Docker daemon's start up process:
[WARN] 2.7 - Do not use the aufs storage driver
Again, you can add a flag to your Docker daemon start up process that will prevent Docker from using the aufs storage driver. Using -s <storage_driver> on your Docker daemon startup, you can tell Docker not to use aufs for storage. It is recommended that you use the best storage driver for the OS on the Docker host that you are using.
If you are using the stock Docker daemon, you should not see any warnings. If you have customized the code in some way, you may get a few warnings here. This is one area where you should hope to never see any warnings.
Let's take a look at the following output for the container images and build files runtime output:
[WARN] 4.1 - Create a user for the container [WARN] * Running as root: suspicious_mccarthy
This states that the suspicious_mccarthy container is running as the root user and it is recommended to create another user to run your containers.
Let's take a look at the output for the container runtime output, as follows:
[WARN] 5.1: - Verify AppArmor Profile, if applicable [WARN] * No AppArmorProfile Found: suspicious_mccarthy
This states that the suspicious_mccarthy container does not have AppArmorProfile, which is the additional security provided in Ubuntu in this case.
[WARN] 5.3 - Verify that containers are running only a single main process [WARN] * Too many processes running: suspicious_mccarthy
This error is pretty straightforward. You will want to make sure that you are only running one process per container. If you are running more than one process, you will want to spread them out across multiple containers and use container linking, as shown in the following command:
[WARN] 5.4 - Restrict Linux Kernel Capabilities within containers [WARN] * Capabilities added: CapAdd=[audit_control] to suspicious_mccarthy
This states that the audit_control capability has been added to this running container. You can use --cap-drop={} from your docker run command to remove the additional capabilities from a container, as follows:
[WARN] 5.6 - Do not mount sensitive host system directories on containers [WARN] * Sensitive directory /etc mounted in: suspicious_mccarthy [WARN] * Sensitive directory /lib mounted in: suspicious_mccarthy [WARN] 5.7 - Do not run ssh within containers [WARN] * Container running sshd: suspicious_mccarthy
This is straight to the point. No need to run SSH inside your containers. You can do everything you want to with your containers using the tools provided by Docker. Ensure that SSH is not running in any container. You can utilize the docker exec command to execute the items against your containers (see more information here: https://docs.docker.com/engine/reference/commandline/exec/), as shown in the following command:
[WARN] 5.10 - Do not use host network mode on container [WARN] * Container running with networking mode 'host': suspicious_mccarthy
The issue with this one is that, when the container was started, the --net=host switch was passed along. It is not recommended to use this as it allows the container to modify the network configuration and open low port numbers as well as access networking services on the Docker host, as follows:
[WARN] 5.11 - Limit memory usage for the container [WARN] * Container running without memory restrictions: suspicious_mccarthy
By default, the containers don't have memory restrictions. This can be dangerous if you are running multiple containers per Docker host. You can use the -m switch while issuing your docker run commands to limit the containers to a certain amount of memory. Values are set in megabytes (that is, 512 MB or 1024 MB), as shown in the following command:
[WARN] 5.12 - Set container CPU priority appropriately [WARN] * The container running without CPU restrictions: suspicious_mccarthy
Like the memory option, you can also set the CPU priority on a per-container basis. This can be done using the --cpu-shares switch while issuing your docker run command. The CPU share is based off of the number 1,024. Therefore, half would be 512 and 25% would be 256. Use 1,024 as the base number to determine the CPU share, as follows:
[WARN] 5.13 - Mount container's root filesystem as readonly [WARN] * Container running with root FS mounted R/W: suspicious_mccarthy
You really want to be using your containers as immutable environments, meaning that they don't write any data inside them. Data should be written out to volumes. Again, you can use the --read-only switch, as follows:
[WARN] 5.16 - Do not share the host's process namespace [WARN] * Host PID namespace being shared with: suspicious_mccarthy
This error arises when you use the --pid=host switch. It is not recommended to use this switch as it breaks the isolation of processes between the container and Docker host.