A container repository is a collection of related container images used to provide different versions of an application. A container typically consists of a container image, which is a file that has anything that a piece of software may need to run -- this includes multiple layers of code, resources and tools. Container repositories will store images for setup and deployment. Organizations can use repositories to manage, pull and push images.
Container image repositories are an integral element of development and deployment practices that make use of containers and PaaS environments. DevOps teams make use of containers, and most teams will pull a variety of container images from numerous sources -- such as open, community-focused registries -- to enable more rapid and flexible application development.
An organization will use a container repository to share container images with its team or with the broader repository platform community. A public repository is one that is shared with a larger community, while a private repository allows an organization to keep its images private within an account or team.
An example of a container repository is a Docker Repository on Docker Hub, which dedicates a location to the storage and publication of Docker images labeled with different tags. The tag is an identifier for an image in a repository.
Container repositories have benefits such as the following:
- They are typically available as a part of container services such as Docker and Kubernetes.
- They allow an organization to share container images either within teams or to larger communities through public or private settings.
- Some container services will give users a free private repository with the creation of an account.
- They increase the speed of the pushing and pulling of images.
- Having large images may lead to performance or latency issues when those images must be pulled from over the internet. Pulling images from a repository within an organization's own infrastructure sidesteps this issue.
- Pulling images from over the internet means an organization has a dependency on the service it gets the images from. If that service goes down or becomes compromised, then the images would become inaccessible. Container repositories also sidestep this potential issue.
Difference between container repository and container registry
At first glance, the term container repository could be confused with a similar term, container registry. While a container repository is a collection of related container images used to manage, pull and push images, a container registry is a collection of repositories made to store container images. Container registries can store container images as well as API paths and access control rules. A registry can be hosted publicly or privately -- like a repository -- or by a third party. However, the important distinction between a registry and repository is that a registry is a collection of repositories, while repositories hold a collection of related images.
A user can act as a host for a container image by placing the image into a container registry for others to access. Utilizing a container registry may be a good idea if, for example, an organization is hosting a native cloud app
As an example, Azure Container Registry is a cloud-based repository built on the open source Docker Registry 2.0. It allows Azure users to store Docker images in repositories with the goal of being able to store each group of images in an isolated environment. Users can control which repository they push images to using the Azure portal. For this, users will need to have created or installed a container registry Docker command-line interface (CLI) and, of course, a container image.
To view a repository in Azure Container Registry, users should sign into the portal, select the registry option and then repositories to see a list of repositories. From there, users can simply select the specific repository they want to view. Azure users should be able to provision their entire container infrastructure in the same Azure region to ensure their image repositories are in the same data center as the container hosts.
How to create a container repository
Using Docker Hub -- a cloud-based repository -- as a primary example, a user can create a repository by signing in and selecting the Repositories option, then selecting the Create Repo option. Users can create a repository in their Docker ID namespace, or any location where the user is an owner. A short and full description is also used in categorization. Short descriptions are a string of 100 characters that are used in search results, while full descriptions create the Readme in the repository. Once selecting the Create option, users will then need to push images to the repository.
Pushing an image to Docker Hub requires users to first name a local image with their Docker Hub username and repository name, then add a tag to it. The image is then uploaded and made available for other users. While Docker Hub offers its registry for free, users must first pay a premium to use Docker Hub as a private repository.
As another example, Google Container Registry also comes with the tools needed to set up a repository. Users of Google Container Registry can set up a repository by creating a pod that uses a secret to pull an image from a private Docker repository. Google Container Registry users need to have a Kubernetes cluster as well as the kubectl command-line tool for this process.
The security of a container repository can be implemented to a specific repository or to a larger registry.
Scanning is one way to ensure that an image or repository is secure. Most organizations that have registry and repository service will support their own scanning. Docker scans, for example, was released in 2016 for official images hosted in Docker Hub, and can be acquired as an add-on for private Docker repositories. Docker Security Scanning can be run when a user selects the dedicated scan option or automatically with any Docker push to a repository. Each layer of an image will be scanned, identifying software components that are in each layer. The scan will index the Secure Hash Algorithms (SHA) of each component and then compare it against the National Vulnerability Database in the user's data transfer rate (DTR) instance.
Users should schedule regular scans of their repository to detect any potential vulnerabilities. This is important since many teams will pull container images from community-focused registries and not all of them are validated or checked for security vulnerabilities.
A Secure Socket Shell (SSH) private key may also be needed when building an app inside a Docker image. The key will either pull code from the private repository, or the user will need security tokens.
To further secure a repository, users should keep images updated to ensure any vulnerable components are patched. Once updated, users should run a new build to create, tag and push an image as a test with the goal of rescanning the image after, ensuring it's free of its vulnerabilities.
Registry security is concerned around compromised containers, vulnerabilities, outdated code and access. Registry security that surrounds repositories includes compromised containers from poorly managed public repositories and individual images. Access is also a concern for registries. Access refers to users with read/write access to an image as well as users who are allowed to edit or delete an image. With a public repository, access is mostly under the control of the repository administrator, as opposed to a private repository where users will need to actively manage access. Private repositories -- such as Docker Hub -- provide users with a basic sense of access control.
Specific registries and repositories will offer different security as well. Amazon Elastic Container Registry markets itself as a secure private container repository, since it encrypts and compresses images at rest. Google Cloud Containers will secure Docker image storage using the Google Cloud Platform and allows control over who can view, access and download images.
Security teams should discuss the available security options for container image repositories with all teams using containers to determine which provide the best sense of security and usability.