% CONTAINERS-REGISTRIES.CONF(5) System-wide registry configuration file % Brent Baude % Aug 2017
containers-registries.conf - Syntax of System Registry Configuration File
The CONTAINERS-REGISTRIES configuration file is a system-wide configuration file for container image registries. The file format is TOML.
Container engines will use the
$HOME/.config/containers/registries.conf if it exists, otherwise they will use
:port] registries to try when pulling an unqualified image, in order.
The bulk of the configuration is represented as an array of
TOML tables; the settings may therefore differ among different registries
as well as among different namespaces/repositories within a registry.
Given an image name, a single
[[registry]] TOML table is chosen based on its
A prefix of the user-specified image name, i.e. using one of the following formats:
The user-specified image name must start with the specified
prefix (and continue
with the appropriate separator) for a particular
[[registry]] TOML table to be
considered; (only) the TOML table with the longest match is used.
As a special case, the
prefix field can be missing; if so, it defaults to the value
location field (described below).
false. By default, container runtimes require TLS when retrieving images from a registry. If
insecureis set to
true, unencrypted HTTP as well as TLS connections with untrusted certificates are allowed.
true, pulling images with matching names is forbidden.
The user-specified image reference is, primarily, a "logical" image name, always used for naming
the image. By default, the image reference also directly specifies the registry and repository
to use, but the following options can be used to redirect the underlying accesses
to different registry servers or locations (e.g. to support configurations with no access to the
internet without having to change
Dockerfiles, or to add redundancy).
Accepts the same format as the
prefix field, and specifies the physical location
By default, this equal to
prefix (in which case
prefix can be omitted and the
[[registry]] TOML table can only specify
prefix = "example.com/foo"
location = "internal-registry-for-example.net/bar"
requests for the image
example.com/foo/myimage:latest will actually work with the
An array of TOML tables specifying (possibly-partial) mirrors for the
The mirrors are attempted in the specified order; the first one that can be
contacted and contains the image will be used (and if none of the mirrors contains the image,
the primary location specified by the
registry.location field, or using the unmodified
user-specified reference, is tried last).
Each TOML table in the
mirror array can contain the following fields, with the same semantics
as if specified in the
[[registry]] TOML table directly:
true, mirrors will only be used during pulling if the image reference includes a digest.
Referencing an image by digest ensures that the same is always used
(whereas referencing an image by a tag may cause different registries to return
different images if the tag mapping is out of sync).
Note that if this is
true, images referenced by a tag will only use the primary
registry, failing if that registry is not accessible.
Note: Redirection and mirrors are currently processed only when reading images, not when pushing to a registry; that may change in the future.
The Docker Hub
docker.io is handled in a special way: every push and pull
operation gets internally normalized with
/library if no other specific
namespace is defined (for example on
(Note that the above-described normalization happens to match the behavior of Docker.)
This means that a pull of
docker.io/alpine will be internally translated to
docker.io/library/alpine. A pull of
docker.io/user/alpine will not be
rewritten because this is already the correct remote path.
Therefore, to remap or mirror the
docker.io images in the (implied)
namespace (or that whole namespace), the prefix and location fields in this
configuration file must explicitly include that
/library namespace. For
prefix = "docker.io/library/alpine" and not
"docker.io/alpine". The latter would match the
repositories but not the
unqualified-search-registries = ["example.com"] [[registry]] prefix = "example.com/foo" insecure = false blocked = false location = "internal-registry-for-example.com/bar" [[registry.mirror]] location = "example-mirror-0.local/mirror-for-foo" [[registry.mirror]] location = "example-mirror-1.local/mirrors/foo" insecure = true
Given the above, a pull of
example.com/foo/image:latest will try:
in order, and use the first one that exists.
VERSION 1 format is still supported but it does not support using registry mirrors, longest-prefix matches, or location rewriting.
The TOML format is used to build a simple list of registries under three
You can list multiple registries using a comma separated list.
Search registries are used when the caller of a container runtime does not fully specify the container image that they want to execute. These registries are prepended onto the front of the specified container image until the named image is found at a registry.
Note that insecure registries can be used for any registry, not just the registries listed under search.
registries.block lists have the same meaning as the
blocked fields in the current version.
The following example configuration defines two searchable registries, one insecure registry, and two blocked registries.
[registries.search] registries = ['registry1.com', 'registry2.com'] [registries.insecure] registries = ['registry3.com'] [registries.block] registries = ['registry.untrusted.com', 'registry.unsafe.com']
We recommend always using fully qualified image names including the registry
server (full dns name), namespace, image name, and tag
(e.g., registry.redhat.io/ubi8/ubi:latest). When using short names, there is
always an inherent risk that the image being pulled could be spoofed. For
example, a user wants to pull an image named
foobar from a registry and
expects it to come from myregistry.com. If myregistry.com is not first in the
search list, an attacker could place a different
foobar image at a registry
earlier in the search list. The user would accidentally pull and run the
attacker's image and code rather than the intended content. We recommend only
adding registries which are completely trusted, i.e. registries which don't
allow unknown or anonymous users to create accounts with arbitrary names. This
will prevent an image from being spoofed, squatted or otherwise made insecure.
If it is necessary to use one of these registries, it should be added at the
end of the list.
It is recommended to use fully-qualified images for pulling as the destination registry is unambiguous. Pulling by digest (i.e., quay.io/repository/name@digest) further eliminates the ambiguity of tags.
Dec 2019, Warning added for unqualified image names by Tom Sweeney firstname.lastname@example.org
Mar 2019, Added additional configuration format by Sascha Grunert email@example.com
Aug 2018, Renamed to containers-registries.conf(5) by Valentin Rothberg firstname.lastname@example.org
Jun 2018, Updated by Tom Sweeney email@example.com
Aug 2017, Originally compiled by Brent Baude firstname.lastname@example.org