GLOBAL SETTINGS

unqualified-search-registries

An array of host[:port] registries to try when pulling an unqualified image, in order.

NAMESPACED [[registry]] SETTINGS

The bulk of the configuration is represented as an array of [[registry]] TOML tables; the settings may therefore differ among different registries as well as among different namespaces/repositories within a registry.

Choosing a [[registry]] TOML table

Given an image name, a single [[registry]] TOML table is chosen based on its prefix field.

prefix

A prefix of the user-specified image name, i.e. using one of the following formats:

Per-namespace settings

insecure

true or false. By default, container runtimes require TLS when retrieving images from a registry. If insecure is set to true, unencrypted HTTP as well as TLS connections with untrusted certificates are allowed.

blocked

true or false. If true, pulling images with matching names is forbidden.

Remapping and mirroring registries

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).

location

Accepts the same format as the prefix field, and specifies the physical location of the prefix-rooted namespace.By default, this equal to prefix (in which case prefix can be omitted and the [[registry]] TOML table can only specify location).Example: Given

prefix = "example.com/foo"
location = "internal-registry-for-example.net/bar"

mirror

An array of TOML tables specifying (possibly-partial) mirrors for the prefix-rooted namespace.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:

mirror-by-digest-only

true or false. If 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.

Short-Name Aliasing

The use of unqualified-search registries entails an ambiguity as it is unclear from which registry a given image, referenced by a short name, may be pulled from.

As mentioned in the note at the end of this man page, using short names is subject to the risk of hitting squatted registry namespaces. If the unqualified-search registries are set to ["registry1.com", "registry2.com"] an attacker may take over a namespace of registry1.com such that an image may be pulled from registry1.com instead of the intended source registry2.com.

While it is highly recommended to always use fully-qualified image references, existing deployments using short names may not be easily changed. To circumvent the aforementioned ambiguity, so called short-name aliases can be configured that point to a fully-qualified image reference.

Short-name aliases can be configured in the [aliases] table in the form of "name"="value" with the left-hand name being the short name (e.g., "image") and the right-hand value being the fully-qualified image reference (e.g., "registry.com/namespace/image"). Note that neither "name" nor "value" can include a tag or digest. Moreover, "name" must be a short name and hence cannot include a registry domain or refer to localhost.

When pulling a short name, the configured aliases table will be used for resolving the short name. If a matching alias is found, it will be used without further consulting the unqualified-search registries list. If no matching alias is found, the behavior can be controlled via the short-name-mode option as described below.

Note that tags and digests are stripped off a user-specified short name for alias resolution. Hence, "image", "image:tag" and "image@digest" all resolve to the same alias (i.e., "image"). Stripped off tags and digests are later appended to the resolved alias.

Further note that drop-in configuration files (see containers-registries.conf.d(5)) can override aliases in the specific loading order of the files. If the "value" of an alias is empty (i.e., ""), the alias will be erased. However, a given "name" may only be specified once in a single config file.

Short-Name Aliasing: Modes

The short-name-mode option supports three modes to control the behaviour of short-name resolution.

If short-name-mode is not specified at all or left empty, default to the permissive mode. If the user-specified short name was not aliased already, the enforcing and permissive mode if prompted, will record a new alias after a successful pull. Note that the recorded alias will be written to /var/cache/containers/short-name-aliases.conf for root to have a clear separation between possibly human-edited registries.conf files and the machine-generated short-name-aliases-conf. Note that $HOME/.cache is used for rootless users. If an alias is specified in a registries.conf file and also the machine-generated short-name-aliases.conf, the short-name-aliases.conf file has precedence.

Normalization of docker.io references

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 docker.io/namespace/image).

(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) /library namespace (or that whole namespace), the prefix and location fields in this configuration file must explicitly include that /library namespace. For example prefix = "docker.io/library/alpine" and not prefix = "docker.io/alpine". The latter would match the docker.io/alpine/* repositories but not the docker.io/[library/]alpine image).

EXAMPLE

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:
1. example-mirror-0.local/mirror-for-foo/image:latest
2. example-mirror-1.local/mirrors/foo/image:latest
3. internal-registry-for-example.net/bar/image:latest

in order, and use the first one that exists.

EXAMPLE

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']