Chapter 3. Working with container registries


To store and retrieve container images and artifacts, you can configure container image registries. The system-wide /etc/containers/registries.conf file manages which registries tools such as, Podman and Buildah use.

3.1. Container registries

A container registry is a repository or collection of repositories for storing container images and container-based application artifacts.

The registries that Red Hat provides are:

  • registry.redhat.io (requires authentication)
  • registry.access.redhat.com (requires no authentication)
  • registry.connect.redhat.com (holds Red Hat Partner Connect program images)

To get container images from a remote registry, such as Red Hat’s own container registry, and add them to your local system, use the podman pull command:

# podman pull <registry>[:<port>]/[<namespace>/]<name>:<tag>

where <registry>[:<port>]/[<namespace>/]<name>:<tag> is the name of the container image.

If there are multiple versions of the same image, add a tag to explicitly specify the image name. By default, Podman uses the :latest tag, for example ubi10/ubi:latest. Some registries also use <namespace> to distinguish between images with the same <name> owned by different users or organizations. For example:

Expand
NamespaceExamples (<namespace>/<name>)

organization

redhat/kubernetes, google/kubernetes

login (user name)

alice/application, bob/application

role

devel/database, test/database, prod/database

Note

Use fully qualified image names including registry, namespace, image name, and tag. When using short names, there is always an inherent risk of spoofing. Add registries that are trusted, that is, registries that do not allow unknown or anonymous users to create accounts with arbitrary names.

3.2. Configuring container registries

To control how Podman searches for and retrieves images, you can configure container registries on RHEL. Defining trusted sources and search priorities ensures predictable application deployment across your infrastructure.

You can display the container registries by using the podman info --format command:

$ podman info -f json | jq '.registries["search"]'
[
  "registry.access.redhat.com",
  "registry.redhat.io",
  "docker.io"
]
Note

The podman info command is available in Podman 4.0.0 or later.

You can edit the list of container registries in the registries.conf configuration file. As a root user, edit the /etc/containers/registries.conf file to change the default system-wide search settings. As a user, create the $HOME/.config/containers/registries.conf file to override the system-wide settings.

unqualified-search-registries = ["registry.access.redhat.com", "registry.redhat.io", "docker.io"]
short-name-mode = "enforcing"

By default, the podman pull and podman search commands search for container images from registries listed in the unqualified-search-registries list in the given order.

Configuring a local container registry

You can configure a local container registry without TLS verification. You have two options to disable TLS verification. First, you can use the --tls-verify=false option in Podman. Second, you can set insecure=true in the registries.conf file:

[[registry]]
location="localhost:5000"
insecure=true
Blocking a registry, namespace, or image

You can define registries the local system is not allowed to access. You can block a specific registry by setting blocked=true.

[[registry]]
location = "registry.example.org"
blocked = true

You can also block a namespace by setting the prefix to prefix="registry.example.org/<namespace>". For example, pulling the image by using the podman pull registry. example.org/example/image:latest command is blocked, because the specified prefix is matched.

[[registry]]
location = "registry.example.org"
prefix="registry.example.org/_<namespace>_"
blocked = true
Note

The prefix is optional, default value is the same as the location value.

You can block a specific image by setting prefix="registry.example.org/namespace/image".

[[registry]]
location = "registry.example.org"
prefix="registry.example.org/_<namespace>_/image"
blocked = true
Mirroring registries

You can set a registry mirror in cases you cannot access the original registry. For example, you cannot connect to the internet, because you work in a highly-sensitive environment. You can specify multiple mirrors that are contacted in the specified order. For example, when you run podman pull registry.example.com/myimage:latest command, the mirror-1.com is tried first, then mirror-2.com.

[[registry]]
location="registry.example.com"
[[registry.mirror]]
location="mirror-1.com"
[[registry.mirror]]
location="mirror-2.com"

For more information, see the podman-pull(1) and podman-info(1) man pages on your system.

3.3. Searching for container images

You can search for images across container registries by using the podman search command. You can also search for images at Red Hat Container Catalog. The catalog includes the image description, contents, health index, and other information.

Note

The podman search command is not a reliable way to determine the presence or existence of an image. The podman search behavior of the v1 and v2 Docker distribution API is specific to the implementation of each registry. Some registries might not support searching at all. Searching without a search term only works for registries that implement the v2 API. The same holds for the docker search command.

To search for the postgresql-10 images in the quay.io registry, follow the steps.

Prerequisites

  • The container-tools meta-package is installed.
  • The registry is configured.

Procedure

  1. Authenticate to the registry:

    # podman login quay.io
  2. Search for the image:

    • To search for a particular image on a specific registry, enter:

      # podman search quay.io/postgresql-10
      INDEX       NAME                                           DESCRIPTION           STARS   OFFICIAL   AUTOMATED
      redhat.io   registry.redhat.io/rhel10/postgresql-10         This container image ...  0
      redhat.io   registry.redhat.io/rhscl/postgresql-10-rhel7   PostgreSQL is an  ...     0
    • Alternatively, to display all images provided by a particular registry, enter:

      # podman search quay.io/*
    • To search for the image name in all registries, enter:

      # podman search postgresql-10

      To display the full descriptions, pass the --no-trunc option to the command. For more information, see the podman-search(1) man page on your system.

3.4. Configuring short-name aliases

Configure short-name aliases in registries.conf to map short names, such as ubi10, to fully qualified image names. This provides control over image sources and helps prevent spoofing risks associated with short names.

Always pull an image by its fully-qualified name. However, it is customary to pull images by short names. For example, you can use ubi10 instead of registry.access.redhat.com/ubi10:latest.

The registries.conf file allows to specify aliases for short names, giving administrators full control over where images are pulled from. Aliases are specified in the table in the form "name" = "value".

You can see the lists of aliases in the /etc/containers/registries.conf.d directory. Red Hat provides a set of aliases in this directory. For example, podman pull ubi10 directly resolves to the right image, that is registry.access.redhat.com/ubi10:latest.

For example:

unqualified-search-registries=["registry.fedoraproject.org", "quay.io"]

[aliases]
"fedora"="registry.fedoraproject.org/fedora"

The short-names modes are:

  • enforcing: If no matching alias is found during the image pull, Podman prompts the user to choose one of the unqualified-search registries. If the selected image is pulled successfully, Podman automatically records a new short-name alias in the $HOME/.cache/containers/short-name-aliases.conf file (rootless user) or in the /var/cache/containers/short-name-aliases.conf (root user). If the user cannot be prompted (for example, stdin or stdout are not a TTY), Podman fails. Note that the short-name-aliases.conf file has precedence over the registries.conf file if both specify the same alias.
  • permissive: Similar to enforcing mode, but Podman does not fail if the user cannot be prompted. Instead, Podman searches in all unqualified-search registries in the given order. Note that no alias is recorded.
  • disabled: All unqualified-search registries are tried in a given order, no alias is recorded.

You can configure Red Hat Enterprise Linux (RHEL) to require and verify container image signatures. This ensures that the images you pull come from a trusted source and are not modified. You can manage this trust policy by modifying the policy.json file, which forces tools, such as Podman, Buildah, and Skopeo to enforce valid container image signatures.

For a system-wide configuration, you can modify the /etc/containers/policy.json file. For rootless users, you can apply these rules in the $HOME/.config/containers/policy.json file.

Scoping policies by transport, registry, and namespace

The policy.json file structures verification rules hierarchically to determine which ones apply to a specific image. You can scope these policies by using the following elements:

  • Default: The default array specifies the fallback policy that applies if an image does not match any of the specifically defined scopes.
  • Transport: You can define custom policies inside the transports object. For container registries, you can define custom policies under the docker transport.
  • Registry and Namespace: You can use the transport section to configure the trust policy at different organizational levels. You scope the policy in either of the following ways:

    • Scope the policy to an entire registry, for example, <registry> for a single-company dedicated registry.
    • Narrow the policy down to a specific namespace or repository, for example, <registry>/<namespace> for a public registry.
Specifying the signature certificate

You can define the signature requirements inside your registry or namespace block to mandate that a corresponding key or certificate must verify an image within a specific scope. You can configure the following key-value pairs:

  • type: signedBy: Instructs the container tools that a valid signature is required.
  • keyType: Specifies the format of the key you are using, for example, GPGKeys.
  • keyPath: Specifies the absolute path to the local public key or certificate file used for verification, for example, testdata/sequoia-key.pgp.

You can configure a default rule to accept everything. However, you can restrict a specific scoped namespace, localhost:5003/simple-sq-signed-centos, within the docker transport to strictly require a valid signature. For example:

{
  "default": [
    {
      "type": "insecureAcceptAnything"
    }
  ],
  "transports": {
    "docker": {
      "localhost:5003/simple-sq-signed-centos": [
        {
          "type": "signedBy",
          "keyType": "GPGKeys",
          "keyPath": "testdata/sequoia-key.pgp"
        }
      ]
    }
  }
}
Note

Once the configuration is active, you must run the podman pull <registry>/<namespace>/<image> command. Podman automatically enforces the signature presence as you configure it in the policy.json file. If you attempt to pull an image from the configured registry that is unsigned or signed with the wrong keys, the command fails.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top