22 new concerns added to Docker security benchmark

CIS-Docker-BenchmarkArticle originally appeared on Network World on April 15th, 2016.

Security has and continues to be an impediment to container adoption. Whether containers are less or more secure than their virtual machine counterparts is a topic of continued debate.

Like any debate, there are merits to arguments on both sides with a bit of FUD interlaced. Many efforts have been undertaken within the container ecosystem to educate adopters and improve their comprehension of available tooling and security postures within platforms and offerings—be that in the form of static analysis (image scanning), runtime vulnerability detection, provenance (image signing), fine-grained authorization, cryptographic verification, etc.

The breadth of need for improved security capabilities has provided an opportunity for emerging start-ups to focus specifically on the container security space and others to dedicate their company’s mission to securing the Internet. Having spent time with most of the vendors in this space, I’ll say that as you might expect, it’s a quickly changing landscape. One thing is evident: open source communities and vendors at every layer—from hardware through operating system, container runtime, container image, host to cluster orchestrator, PaaS to CaaS—have significantly marshalled forward security-centered improvements in the past year.

The Center for Internet Security (CIS) is one of those organizations. CIS is dedicated to enhancing cybersecurity readiness and response between both public and private sectors. CIS produces Security Benchmarks as a way of providing defined, unbiased and consensus-based industry best practices to help organizations assess and improve their security. Thanks to a community of collaborators (disclaimer: I am a member of the CIS Docker Benchmarks working group), the first CIS Docker Benchmark was published last April for Docker 1.6. A year later (April 13, 2016), a revision of this benchmark was released in concert with the Docker 1.11.0 release.

Each CIS Docker Benchmark provides prescriptive guidance (in the form of rules) for establishing a secure configuration posture for Docker container infrastructure. The new benchmark version has been published with 22 new rules added and 23 rules removed, netting 83 rules in total.

As Docker has evolved over the past year, several rules have been updated or simply removed, as these concerns are now addressed in later versions of Docker tooling. Other updates in the rules are simply a reflection of architectural shifts Docker has made. In the 1.11.0 release, Docker has separated the concern of supervising containers and their runtime, splitting into two daemons: containerd and runc.

The benchmark categorizes Docker security concerns into these groups (with number of concerns in parenthesis):

  • Host Configuration (15)
  • Docker daemon configuration (13)
  • Docker daemon configuration files (20)
  • Container Images and Build File (5)
  • Container Runtime (25)
  • Docker Security Operations (5)

Each rule not only describes the security concern and how to perform an audit to ascertain your deployment’s disposition, but also suggests how you may remediate the concern. Both rules and their remediations are written from the perspective of a container host, not a cluster, so how you choose to remediate the concern will vary based on your cluster size and platform choice (bare metal, container PaaS, cloud, etc.)

New rules introduced in the CIS Docker 1.11.0 Benchmark (pdf):

  • Host Configuration
    • 1.11 Audit Docker files and directories – docker.socket
    • 1.13 Audit Docker files and directories – /etc/docker/daemon.json
    • 1.14 Audit Docker files and directories – /usr/bin/docker-containerd
    • 1.15 Audit Docker files and directories – /usr/bin/docker-runc
  • Docker Daemon Configuration
    • 2.8 Enable user namespace support
    • 2.9 Confirm default cgroup usage
    • 2.10 Do not change base device size until needed
    • 2.11 Use authorization plugin
    • 2.12 Configure centralized and remote logging
    • 2.13 Disable operations on legacy registry (v1)
  • Docker Daemon Configuration Files
    • 3.17 Verify that daemon.json file ownership is set to root:root
    • 3.18 Verify that daemon.json file permissions are set to 644 or more restrictive
    • 3.19 Verify that /etc/default/docker file ownership is set to root:root
    • 3.20 Verify that /etc/default/docker file permissions are set to 644 or more restrictive
  • Container Images and Build File
    • 4.5 Enable Content trust for Docker
  • Container Runtime
    • 5.19 Do not set mount propagation mode to shared
    • 5.20 Do not share the host’s UTS namespace
    • 5.21 Do not disable default seccomp profile
    • 5.22 Do not docker exec commands with privileged option
    • 5.23 Do not docker exec commands with user option
    • 5.24 Confirm cgroup usage
    • 5.25 Restrict container from acquiring additional privileges

Some container security vendors participate in the creation of the Docker Security Benchmark, while many others incorporate detection of these issues into their offering or project. While some include policy-driven orchestration to address failed security tests, few actually fully remediate the issue (only some issues are well-suited for automated remediation).

Security Configuration Benchmarks are distributed free of charge to propagate their worldwide use and adoption as user-originated standards. One such tool adopting the 1.11.0 benchmark concerns is the Docker Bench for Security—an open source, command-line tool used to perform checks in accordance with the CIS Docker Benchmark.

Lee Calcote

Lee Calcote
Lee Calcote is an innovative thought leader, passionate about developer platforms and management software for clouds, containers, infrastructure and applications. Advanced and emerging technologies have been a consistent focus through Calcote’s tenure at SolarWinds, Seagate, Cisco and Pelco. An organizer of technology meetups and conferences, a writer, author, speaker, he is active in the tech community.

Talk - Service Meshes, but at what cost

As you learn of the architecture and value provided by service meshes, you’re intrigued and initially impressed. Upon reflection, you, li...… Continue reading