Contributor

22 new concerns added to Docker security benchmark

opinion
Apr 15, 20164 mins

The Center for Internet Security released the second version of the Docker Security Benchmark in conjunction with the Docker 1.11.0 release

p:bigbite/multi-title –>

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 is an innovative thought leader, passionate about developer platforms and management software for clouds, containers, networks and systems. Advanced and emerging technologies have been a consistent focus through Calcote’s tenure at Seagate, Cisco and Pelco. Calcote has nearly two decades of combined technical and management experience with globally distributed, agile engineering teams and responsibility for product and services strategy, management, partnership, development and delivery.

While leading the charge to create and deliver Seagate’s first microservices, Calcote served as a Director of Software Engineering of Cloud Systems and Solutions. Prior to Seagate, as a Senior Software Engineering Manager in Cisco's Cloud and Virtualization Group, Calcote has led engineering of Cisco's cloud management platform - Cisco Intelligent Automation for Cloud. His product and teams founded architecture for the Intercloud platform, focusing on technologies supporting cloud-native and enterprise-architected applications from an OpenStack-centric perspective. He established the Docker@Cisco community and stewarded use of container technology by fostering its use within existing and new product offerings. Previously part of the Smart Services Technology Group at Cisco, Calcote led development of network management systems utilized by Cisco Remote Management Services.

Calcote joined Cisco in 2008, bringing a decade of technological expertise from a variety of roles previously held. As a faculty member of California State University, Fresno, he lectured to budding technologists in the Cisco Networking Academy Program. He served on advisory boards to the Fresno City College and Clovis East High School. He currently serves as a member of the DMTF, an organizer of two Austin-based meetups on Docker and Microservices, Container Days, an advisor to container security startup, writes for The New Stack and has a Kubernetes book in-progress.

Calcote holds a bachelor’s degree in computer science and a master’s degree in business administration from California State University, Fresno. He also retains a list of industry certifications. Connect with Lee at LinkedIn and Twitter.

The opinions expressed in this blog are those of Lee Calcote and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author