Docker Security – part 4(Container image)

This is the fourth part of my Docker security series. In this blog, I will cover ways to secure Container images. Following are the other parts (1, 2, 3).

Docker image signing:

The most critical part with Docker is the Container image as ultimately the platform is being used to develop and deploy Container images. Docker Container images can be stored either in public or private registry. It is needed to sign Container images so that the client knows that image is coming from a trusted source and that it is not tampered with. Content publisher takes care of signing Container image and pushing it into the registry.
Following are some details on Docker content trust:

• The Docker content trust is an implementation of the Notary open source project. The Notary open source project is based on The Update Framework (TUF) project.
• Docker content trust is enabled with “export DOCKER_CONTENT_TRUST=1”. As of Docker version 1.10, content trust is not enabled by default. In later releases, this will be changed to enable Content trust by default.
• When content trust is enabled, we can pull only signed images. When image is pushed, we need to enter tagging key.
• When content trust is not enabled, both signed and unsigned images can be pulled.

• When the publisher pushes the image for the first time using docker push, there is a need to enter a passphrase for the root key and tagging key. Other keys are generated automatically.
• Docker has also added support for hardware keys using Yubikey and details are available here.

Following is the error we get when content trust is enabled and image is not signed.

$ docker pull smakam/mybusybox
Using default tag: latest
No trust data for latest

Following output shows Container image being pushed to Docker hub with signing enabled. Since this is not the first time, user is requested to enter only the passphrase for repository key.

$ docker push smakam/mybusybox:v2
The push refers to a repository [docker.io/smakam/mybusybox]
a7022f99b0cc: Layer already exists 
5f70bf18a086: Layer already exists 
9508eff2c687: Layer already exists 
v2: digest: sha256:8509fa814029e1c1baf7696b36f0b273492b87f59554a33589e1bd6283557fc9 size: 2205
Signing and pushing trust metadata
Enter passphrase for repository key with ID 001986b (docker.io/smakam/mybusybox): 

It is needed to store root key, repository key as well as passphrase in a safe place. Following command can be used to take backup of private keys:

tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private

When I changed Docker host, I had to move the root keys and repository keys to operate from the new host.

Container image scanning:

Docker recently introduced a project called Nautilus that scans Container images for vulnerabilities. Nautilus is not yet officially released. Following are some details on Nautilus:

• The initial goal is to scan official Docker images in Docker hub. It will be extended later to private images, Docker trusted registry and private registry.
• In addition to checking image security, license check and dependency check are other features targeted as part of Nautilus.
• Image security is done by scanning each image layer in Dockerfile and comparing with vulnerability repository.
• Nautilus is useful for both content publisher and user.
• Nautilus plans to pro-actively give notifications to both the publisher and user of Container images.

Docker trusted registry:

Docker trusted registry (DTR) is a paid service from Docker that gives few additional features compared to Docker hub like:

• On-premise registry, more secure
• Role based access control
• Integration with ldap and active directory
• Gives health and score card

DTR is a paid service. For folks who don’t want to use Docker hub or DTR, they can use open source project docker registry 2.0. It is necessary to use TLS between Docker engine and Docker registry irrespective of the type of registry being used.

In this Docker security series, we covered different aspects of Docker security as well as best practices in using them. There are more Docker security enhancements planned in release 1.11 and beyond.

References:

• Docker content trust documentation
• Docker official repos and Nautilus presentation