Docker Security Best Practices: 2018 Wrap-Up

60 VIEWS

·

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

Do you think you can beat this Sweet post?

If so, you may have what it takes to become a Sweetcode contributor... Learn More.

Michael Churchman is a Fixate IO contributor. He started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the ‘90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards.


Discussion

Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

Menu