Docker is designed to be secure by default. But like most such things, Docker can be made even more secure. This article helps you do that by discussing the key concepts that you should embrace for securing Docker containers , as well as resources you can use to learn more about Docker security best practices.
For containers, security must be baked into infrastructure ― and that starts with the security resources that are available as part of Docker Community Edition and Docker Enterprise. This page presents a running list of built-in Docker security features, along with a look at add-on resources which provide extended security for Docker-based container systems.Key Docker Elements
The following components of the Docker platform are fundamental to Docker’s operation, and as such, they play a vital role in establishing and maintaining Docker security:Docker Hub
Docker Hub is Docker’s cloud-based image registry service. It includes over half a million public container images (many of them in official and community repositories), and has supported over 6 billion image pulls. Developers can publish and distribute images, as well as access images published by other developers.
Access to public repositories is free; the free level of use includes one private repository. There are several paid plans for use of larger numbers of private repositories.
Because private repositories are private, and official repositories are maintained by organizations with (presumably) known security standards and practices, Docker Hub by itself can provide some very basic levels of container security. To be truly secure, however, it does require additional resources.
Docker Hub: https://docs.docker.com/docker-hub/Docker Trusted Registry
Docker Trusted Registry is the registry service that comes with Docker Enterprise Edition. It is similar to Docker Hub, but, like other major elements of Docker’s premium, subscription-based Enterprise platform, it is designed to meet both the scaling and security requirements of enterprise users. It uses repository replication and caching to maintain a high level of availability and efficiency. DTR can operate from a virtual private cloud, or on-premises. (You would typically install it behind your firewall.)
Docker Trusted Registry: https://docs.docker.com/ee/dtr/Official Repositories
The official repositories hosted on Docker Hub make available the most important operating systems, programming language runtimes, and other key resources in curated sets of container images and support files. These repositories are maintained through a collaborative effort involving dedicated Docker staff, upstream providers, and public participation. They serve as a readily available set of standard, up-to-date resources which can be used by both new and experienced container developers. They also serve as best-practice examples and references for container users and developers.
Official Repositories: https://hub.docker.com/explore/Standard Docker Security Features and Resources
The standard security resources listed below form the key elements of Docker’s built-in security:Docker Content Trust
Content Trust is a system for using client-side digital signatures to verify the integrity of container images, their publishers, and the data that they contain. It uses two keys (a Tagging Key and an Offline Key) in conjunction with The Update Framework (TUF) to provide protection against man-in-the-middle, replay, and other attacks. Developers can use Content Trust to selectively protect images intended for distribution, and users with Content Trust enabled will only have access to protected images.
The Offline Key, along with a built-in key hierarchy made possible by TUF, provides protection against compromised or otherwise lost keys. For added security, the Offline Key can be stored on a USB-based touch-to-sign Yubikey; Docker gives priority to a key stored on a Yubikey when it is present.
More on Content Trust: https://docs.docker.com/engine/security/trust/content_trust/
The original Content Trust introduction: https://blog.docker.com/2015/08/content-trust-docker-1-8/Docker Notary
Docker Content Trust is closely associated with Notary, which also uses The Update Framework (TUF). Notary is a system for providing secure content over networks which may not themselves be secure. Like Content Trust, it uses offline keys (with Yubikey support) maintained by the publisher, and public keys which are available to consumers for verification. Notary uses a server-client model, with the Notary server maintaining and managing TUF metadata, while a separate Notary signer manages private keys and metadata for the server itself.
The Notary CLI can be used with Content Trust to verify public Docker repositories. Docker Hub includes its own Notary servers, and each Docker Hub repository by default includes a trust directory containing the required metadata. You can also set up and run your own Notary server (for use with a private registry, for example), both for testing/development, and for production.
Notary on GitHub: https://github.com/theupdateframework/notary
The original Notary Introduction: https://blog.docker.com/2016/03/notary-0-2/
Docker Notary documentation: https://docs.docker.com/notary/getting_started/Docker Security Scanning (formerly Project Nautilus)
Docker Security Scan scans container images for vulnerabilities. It is currently available (with separate licensing) for Docker Enterprise Edition, and it requires Docker Trusted Registry. For enterprise-level users, Docker Security Scan can be an extremely important tool for maintaining the security and integrity of containers used within an organization and those provided to clients.
Note: Docker Security Scanning (under that name, and in its earlier incarnation as Project Nautilus) had previously been available to users as a free preview. While the free version has been discontinued, Docker has indicated that it eventually intends to provide some form of scanning for public repositories.
Docker Security Scanning Documentation: https://docs.docker.com/datacenter/dtr/2.4/guides/admin/configure/set-up-vulnerability-scans/Third-Party Docker Security Resources
Needless to say, when it comes to a platform as important as Docker, a wide range of third-party security services and tools are available, including Twistlock’s own comprehensive set of security resources. Here, we would like to spotlight one such resource, Twistlock’s own AuthZ broker.Twistlock AuthZ Broker
The AuthZ broker is an authorization framework for Docker, originally developed by Twistlock, and since the release of Docker 1.10, it has been included as a part of Docker itself. It allows you to create plugins with fine-grained control over access to Docker commands. This means that AuthZ plugins can manage individual client access to specific commands and elements of the Docker API. This control can take into account details of both the authentication context (client identity, etc.) and the command context (API function, target container, data payload, and so on).
AuthZ extends Docker’s original authentication system, which was essentially all-or-none: You were either allowed access to the entire Docker API, or were denied access. By providing fine-grained access control, AuthZ makes it possible for developers to allow specific client/user access to individual Docker API commands on a per-need or per-context basis, while at the same time tightly restricting access to the overall container infrastructure.
AuthZ on GitHub: https://github.com/twistlock/authz
The original AuthZ introduction: https://www.twistlock.com/2016/02/18/docker-authz-plugins
Docker’s AuthZ documentation: https://docs.docker.com/engine/extend/plugins_authorization/Other Resources Here is a good Q&A with Docker (albeit from 2015) on the various Docker security resources features. Docker Blog Post: Introducing Docker Secrets Management Docker Blog Post: A Secure Supply Chain for Kubernetes Docker and Docker security . CIS Docker Community Edition Benchmark . This document defines the security configuration best practices for the linux host, the Docker daemon and Docker Swarm, and container images, build files, and runtime operations. “ Are Docker containers really secure? ” This is the original post in which Daniel J. Walsh (head of the Red Hat Docker enablement team) explains why “containers do not contain” ― and what that means for container security.
Do you think you can beat this Sweet post? If so, you may have what it takes to become a Sweetcode contributor...Learn More.