Red Hat SummitChapter 1. Overview
This guide provides recommendations for container development that are supported by Red Hat. Though containers, in their current Docker-driven implementation, are a new and rapidly-developing technology, this guide captures the state of container support within Red Hat. Because there are many use cases for containers, this guide provides general recommendations about fundamental container-related practices that are useful and supported by Red Hat.
1.1. Container Provenance
Where do containers come from? How do we get them? How do we make sure that we get them in a secure manner?
Containers are built from images, and images are stored in repositories on registries. This topic discusses two registries that the command docker pull can access:
-
The
docker.ioregistry - [The Red Hat Registry](http://registry.access.redhat.com/)
1.1.1. The Risks of "docker pull"
The docker pull command, used without the registry from which you are pulling, is a potentially dangerous command. Docker makes no distinction between retrieval of software and installation of software. This behavior is different from the case of an RPM: it is safe to use wget to retrieve an RPM that contains malware as long as you do not install the RPM. If is not safe, however, to pull malware using docker pull because retrieving an image is functionally equivalent to installing it.
For example, assume that containers are software that upon retrieval runs as privileged. Containers relinquish privilege only after having their settings manipulated. The isolation of containers is usually voluntary, and they are not isolated by default.
Exercise caution when using the docker pull command.
If a container is not found in the Red Hat Registry, docker pull fails over to the docker.io registry. Red Hat does not verify the security or authenticity of containers from third-party sources, such as docker.io. See also the Image-Naming Conventions chapter.
When retrieving images from places other than the Red Hat Registry, avoid docker pull. If possible, use docker load and docker save. You can use docker load and docker save with tarballs and then verify the images.
Why would you want to use docker load and docker save instead of docker pull? docker load and docker save provide a way to avoid the security vulnerability introduced by exposing your system to third-party registries, which could happen when you run docker pull.
For more information on container provenance and exercising caution when using docker pull, see Red Hat’s Security Blog post Before You Initiate a "docker pull".
- docker pull
The basic form of docker pull is: $ sudo docker pull repo/image:tag where repo and tag are optional. If repo and tag are not specified, docker will attempt to locate the image in the docker.io registry. For this reason, it is advisable always to explicitly name the registry from which you want to pull the image. If no registry is specified, docker attempts to find an image on the docker.io registry. If no tag is supplied, docker attempts by default to pull the latest image.
- docker load
The basic form of docker load is: $ sudo docker load -i input.tar where input.tar is a tar image to be loaded into your local container registry. The -i is optional and the input.tar file name is optional. If neither -i nor a file name is specified, docker load expects tar data on STDIN.
- docker save
The basic form of docker save is: $ sudo docker save -o output.tar where output.tar is a tar image to be loaded into your local container registry. The -o is optional and the output.tar file name is optional. If neither -o nor a file name is specified, docker save will output container data to STDOUT.
