Docker CIS Benchmark: Best Practices in Brief

Get the gist of the Docker CIS Benchmark recommendations for host configuration, Docker Daemon configuration and more, and learn to automate security testing.

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

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 ToConfiguration ElementRecommendation
All HostsHost operating systemEnsure the OS is hardened
Docker binaryEnsure Docker version is up to date
Linux HostsDisk partitionsCreate a separate partition for containers
User accountsOnly 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 ElementRecommended Setting
Network traffic between containers on default bridgerestricted
Logging levelinfo
Docker permission to make changes to iptablesallow
Insecure registriesdo not use
Aufs storage driverdo not use
TLS authenticationuse and configure correctly
Default ulimitconfigure as appropriate
User namespace supportenabled
Default cgroup usageconfirm it is used
Base device sizedo not change until needed
Docker client command authorizationenabled
Centralized loggingconfigured
Remote loggingconfigured
Live restoreenabled
Userland Proxydisabled
Custom seccomp profileapplied if appropriate
Experimental featuresdo not use in production
Container ability to gain new privilegesrestricted

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 SecureFile PermissionsFile Ownership
docker.service fileas appropriateroot:root
docker.socket file644 or stricterroot:root
/etc/docker directory755 or stricterroot:root
registry certificate file444 or stricterroot:root
TLS CA certificate file444 or stricterroot:root
Docker server certificate file444 or stricterroot:root
Docker server certificate key file400 or stricterroot:root
Docker socket file660 or stricterroot:docker
daemon.json file644 or stricterroot:root
/etc/default/docker file644 or stricterroot:root
/etc/sysconfig/docker file644 or stricterroot: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 ElementRecommendations
Permissions1. Create a user for the container
2. Remove setuid and setgid permissions
Container content1. Avoid unnecessary packages in the container
2. Only install verified packages
3. Define HEALTHCHECK instructions for the container
4. Enable content trust for Docker
Images1. Only use trusted base images
2. Perform security scans on images
3. Rebuild images to include security patches
Dockerfiles1. 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 recommendations for container startup and runtime configuration.

Configuration ElementRecommended Setting
AppArmor Profileenabled (if applicable)
SELinux security optionsset (if applicable)
Linux kernelaccess restricted within containers
Privileged containersdo not use
Sensitive host directoriesnever mount on a container
sshdnever run on a container
ports 1. Do not map privileged ports in containers
2. Only open needed ports
Host network namespace, IPC namespace, UTS namespacedo not set to shared
Container resource utilization1. Limit memory usage
2. Set CPU priority
Container root file systemmount as read only
Incoming container trafficrestrict to specific host interface
‘on-failure’ restart policy5
Host devicesdo not expose to containers
Default ulimitoverwrite at runtime if needed
Mount propagationdo not set to shared
Default seccomp profiledo not disable
Docker exec commands1. Do not use with privileged option
2. Do not use with user=root
cgroup1. confirm it is used
2. ensure PIDs cgroup limit is used
container additional privilegesrestrict
container health checkalways perform at runtime
Docker commandsalways use latest version of image
Docker default bridge “docker0”do not use
Docker socketnever 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 ElementRecommended Setting
swarm modeonly enable if needed
manager nodescreate as few as possible
swarm servicesbind to specific host interface
swarm overlay networksencrypt
swarm secretsUse Docker secret management commands
swarm manager modeauto-lock
Management plane traffic separate from data plane traffic
swarm manager auto-lock keyperiodically 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 ToConfiguration ElementRecommendation
Universal Control PlaneLDAP authenticationconfigure
External certificatesuse
client certificate bundles for unprivileged usersenforce usage
client role-based access control (RBAC)enforce usage
signed imagesenforce usage
per-user session limitset to 3 or lower
lifetime minutesset to 15 or lower
renewal threshold minutesset to 0
Docker Trusted Registryimage vulnerability scanningenable

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.

The Cloud Native Experts
"The Cloud Native Experts" at Aqua Security specialize in cloud technology and cybersecurity. They focus on advancing cloud-native applications, offering insights into containers, Kubernetes, and cloud infrastructure. Their work revolves around enhancing security in cloud environments and developing solutions to new challenges.