What is Docker CIS Benchmark?
The Center for Internet Security (CIS) researches best practices for cybersecurity in containerized environments. CIS publishes the Docker CIS Benchmark, a comprehensive list of best practices that can help you secure Docker containers in production.
The Docker CIS Benchmark focuses on ensuring Docker containers runtimes are configured as securely as possible. You can download the full Docker CIS Benchmark for free from the Center for Internet Security.
This post summarizes Docker security best practices in the CIS benchmark, and provides details on three tools that can automatically test for Docker security best practices.
In this article, you will learn:
- Docker CIS Benchmark Best Practices
- Host Configuration
- Docker Daemon Configuration
- Docker Daemon Configuration Files
- Container Images and Build File Configuration
- Container Runtime Configuration
- Docker Security Operations
- Docker Swarm Configuration
- Docker Enterprise Configuration
- Docker Security Benchmark Tools
- Docker Bench for Security
- OpenSCAP Workbench
- Anchore
Docker CIS Benchmark Best Practices
The Docker CIS Benchmark is an extensive document with detailed recommendations about securing Docker in production. Below we provide a summary of the recommendations to help you get a head start on the CIS best practices.
Related content: read our guide to Docker architecture ›
Host Configuration
The CIS benchmark has several recommendations for securing the host on which the Docker engine runs.
Applies To | Configuration Element | Recommendation |
All Hosts | Host operating system | Ensure the OS is hardened |
Docker binary | Ensure Docker version is up to date | |
Linux Hosts | Disk partitions | Create a separate partition for containers |
User accounts | Only grant access to Docker daemon to trusted users | |
Docker files and directories, in particular: Docker.service Docker.socker /etc/default/docker /etc/docker/daemon.json /usr/bin/containerd /usr/sbin/runc | Ensure auditing is configured |
Docker Daemon Configuration
Here are the CIS recommendations for securing the behavior of the Docker daemon, the background process that manages all containers on the Docker host.
Configuration Element | Recommended Setting |
Network traffic between containers on default bridge | restricted |
Logging level | info |
Docker permission to make changes to iptables | allow |
Insecure registries | do not use |
Aufs storage driver | do not use |
TLS authentication | use and configure correctly |
Default ulimit | configure as appropriate |
User namespace support | enabled |
Default cgroup usage | confirm it is used |
Base device size | do not change until needed |
Docker client command authorization | enabled |
Centralized logging | configured |
Remote logging | configured |
Live restore | enabled |
Userland Proxy | disabled |
Custom seccomp profile | applied if appropriate |
Experimental features | do not use in production |
Container ability to gain new privileges | restricted |
Related content: read our guide to seccomp ›
Docker Daemon Configuration Files
The Docker Daemon configuration files are highly sensitive and can allow an attacker to control all containers on the host. Here are the CIS recommendations for securing these files.
This section covers Docker related files and directory permissions and ownership. Keeping the files and directories, that may contain sensitive parameters, secure is important for correct and secure functioning of Docker daemon.
File/Directory to Secure | File Permissions | File Ownership |
docker.service file | as appropriate | root:root |
docker.socket file | 644 or stricter | root:root |
/etc/docker directory | 755 or stricter | root:root |
registry certificate file | 444 or stricter | root:root |
TLS CA certificate file | 444 or stricter | root:root |
Docker server certificate file | 444 or stricter | root:root |
Docker server certificate key file | 400 or stricter | root:root |
Docker socket file | 660 or stricter | root:docker |
daemon.json file | 644 or stricter | root:root |
/etc/default/docker file | 644 or stricter | root:root |
/etc/sysconfig/docker file | 644 or stricter | root:root |
Container Images and Build File Configuration
Container base images and the build files used to create them dictate what is inside a container and how it operates. Ensure your base images and build files are safe and trusted. Here are CIS recommendations for images.
Configuration Element | Recommendations |
Permissions | 1. Create a user for the container 2. Remove setuid and setgid permissions |
Container content | 1. Avoid unnecessary packages in the container 2. Only install verified packages 3. Define HEALTHCHECK instructions for the container 4. Enable content trust for Docker |
Images | 1. Only use trusted base images 2. Perform security scans on images 3. Rebuild images to include security patches |
Dockerfiles | 1. Ensure update instructions are not use alone 2. Use COPY instead of ADD 3. Do not store secrets in Dockerfiles |
Container Runtime Configuration
The way a container is configured to start has a major impact on security. Certain runtime parameters can lead to compromise of the host and the containers running on it. Here are CIS recomendations for container startup and runtime configuration.
Configuration Element | Recommended Setting |
AppArmor Profile | enabled (if applicable) |
SELinux security options | set (if applicable) |
Linux kernel | access restricted within containers |
Privileged containers | do not use |
Sensitive host directories | never mount on a container |
sshd | never run on a container |
ports | 1. Do not map privileged ports in containers 2. Only open needed ports |
Host network namespace, IPC namespace, UTS namespace | do not set to shared |
Container resource utilization | 1. Limit memory usage 2. Set CPU priority |
Container root file system | mount as read only |
Incoming container traffic | restrict to specific host interface |
‘on-failure’ restart policy | 5 |
Host devices | do not expose to containers |
Default ulimit | overwrite at runtime if needed |
Mount propagation | do not set to shared |
Default seccomp profile | do not disable |
Docker exec commands | 1. Do not use with privileged option 2. Do not use with user=root |
cgroup | 1. confirm it is used 2. ensure PIDs cgroup limit is used |
container additional privileges | restrict |
container health check | always perform at runtime |
Docker commands | always use latest version of image |
Docker default bridge “docker0” | do not use |
Docker socket | never mount inside containers |
Docker Security Operations
Here are two key CIS recommendations with regard to securely operating Docker in production:
- Avoid image sprawl—it is a best practice not to use too many container images on the same host. All images on the host must be tagged. Untagged images or images with old tags may contain vulnerabilities.
- Avoid container sprawl—do not run too many containers on the same host. Having more containers on the host than optimal can expose the Docker host to mishandling, misconfiguration, and fragmentation.
Docker Swarm Configuration
Docker Swarm is Docker’s container orchestrator, which can manage clusters of containers and their lifecycle. Here are CIS recommendations for running Docker Swarm securely.
Configuration Element | Recommended Setting |
swarm mode | only enable if needed |
manager nodes | create as few as possible |
swarm services | bind to specific host interface |
swarm overlay networks | encrypt |
swarm secrets | Use Docker secret management commands |
swarm manager mode | auto-lock |
Management plane traffic | separate from data plane traffic |
swarm manager auto-lock key | periodically rotate |
Node certificates | |
CA certificates |
Docker Enterprise Configuration
Docker Enterprise Edition (EE) by Mirantis is Docker’s enterprise-grade container platform for CentOS, RHEL, SUSE Linux Enterprise, Oracle Linux, and Windows Server. Here are CIS recommendations for securely running Docker EE.
Applies To | Configuration Element | Recommendation |
Universal Control Plane | LDAP authentication | configure |
External certificates | use | |
client certificate bundles for unprivileged users | enforce usage | |
client role-based access control (RBAC) | enforce usage | |
signed images | enforce usage | |
per-user session limit | set to 3 or lower | |
lifetime minutes | set to 15 or lower | |
renewal threshold minutes | set to 0 | |
Docker Trusted Registry | image vulnerability scanning | enable |
Related content: read our guide to container registry scanning ›
Docker Security Benchmark Tools
The Docker CIS Benchmark provides hundreds of detailed recommendations for Docker configuration. It is impractical to manually check all these best practices, especially for large container deployments. Below are three free tools that can help you automatically test that your containers meet the CIS best practices, and provide suggestions for remediation.
Docker Bench for Security
Docker Bench for Security is an open source script that audits containers according to the CIS benchmark’s best practices. It performs tests based on CIS benchmark recommendations, and logs its findings.
For each CIS benchmark recommendation, the tool provides Info (issues found), Warning (container does not meet the recommendation), or Pass (container is compliant). You can run the tool from the Docker host, directly on the host operating system, or clone it with Docker Compose.
OpenSCAP Workbench
OpenSCAP includes multiple open security benchmark guidelines, configuration criteria, and open source tools that can help test for security issues, including the CIS benchmark. It is focused on the NIST-certified Secure Content Automation Protocol (SCAP), which includes many automated security policies.
OpenSCAP goes wider than the CIS recommendations, including many other recommendations, some of which are not specific to a containerized environment. It can be useful for identifying additional security concerns not covered by the CIS guidelines.
Anchore
Anchore Engine is a tool for analyzing container images. It can identify CVE-based vulnerabilities in containers, and also lets users define custom policies and use them to evaluate Docker images. Policies can be based on whitelist, blacklist, credentials, file contents, and configurations.
While anchor does not officially support CIS benchmark guidelines, you can define custom policies to cover all benchmark recommendations. For each policy, Anchore returns a pass or fail result.
Anchor can run as a Docker container image, within Kubernetes, or as a standalone binary. It integrates with popular CI/CD tools like Jenkins and GitLab.