13 Container Registries

Use the container registries configured with Podman to pull container images. Create a self-hosted container registry, and create registry mirrors.

A container registry is a store of Open Container Initiative images. A container image is a read-only template which is used to create running containers. Container images in the registry can be deployed as required.

By default, Oracle Linux systems are configured with access to these commonly used registries:

  • Oracle Container Registry (container-registry.oracle.com)

  • Docker Hub (docker.io)

You can configure the container runtime to only trust images from container registries if they're signed to improve security and mitigate against inadvertently running a compromised image. For more information, see Configuring Podman for Signed Images.

Enterprise environments might also consider setting up a local container registry. The local container registry can store images converted from customized containers. You can then use these images for future container deployment. Storing images in a local container registry reduces the amount of customized configuration that you might need to perform for mass deployments. A local registry can also cache and host images that are pulled from an upstream registry, which further reduces network overhead and latency when you deploy matching containers across a spread of local systems.

Oracle Container Registry

Use the Oracle Container Registry to pull open source and licensed Oracle software container images.

The Oracle Container Registry is an open standards-based, Oracle-managed container registry service for securely storing and sharing container images. The Oracle Container Registry contains both licensed and open source Oracle software, and the images are built and signed by Oracle. Use of the container images is subject to the terms of their respective licenses.

The Oracle Container Registry is at https://container-registry.oracle.com. It provides a web interface to browse and select the images for the software that an organization can use. Oracle Container Registry hosts container images for both open source and licensed Oracle products. Licensed content requires you to authenticate and accept license agreement terms before downloading images. Before you can sign in, you must generate an authentication token.

Note:

You don't need to create an authentication token and sign in to Oracle Container Registry to pull open source container images, as this is only required for licensed images.

You can use one of the Oracle Container Registry mirrors for faster download in different geographical regions.

Pulling Open Source Software From the Oracle Container Registry

The correct command to pull an image is provided on the repository information page in the Oracle Container Registry web interface. Other useful information about the image and how to run it might also be available on the same page.

If you're using an Oracle Container Registry mirror, change the URL in these steps to use the URL of the mirror. For more information on using mirrors, see Using Oracle Container Registry Mirrors.

To pull an image from the Oracle Container Registry, use the following podman pull command:

podman pull container-registry.oracle.com/area/image:tag

Replace area with the repository location in the Oracle Container Registry, and image with the name of the software image. For example:

podman pull container-registry.oracle.com/os/oraclelinux:9-slim

The area and image are specified in lowercase. When referencing images, we recommend that you always specify the appropriate tag to use.

For more information on the tagging conventions for Oracle Linux images, see Oracle Linux Container Image Tagging Conventions.

Pulling Licensed Software From the Oracle Container Registry

The Oracle Container Registry contains images for licensed commercial Oracle software products. To pull images for licensed software on the Oracle Container Registry, you must have an Oracle Account and have created an authentication token. You can create an Oracle Account at https://profile.oracle.com/myprofile/account/create-account.jspx. For information on creating an authentication token, see Generating an Oracle Container Registry Authentication Token.

Note:

You don't need to sign in to the Oracle Container Registry or accept the Oracle Standard Terms and Restrictions to pull open source Oracle software images, only for licensed software images.

If you're using an Oracle Container Registry mirror, change the URL in these steps to use the URL of the mirror. For more information on using mirrors, see Using Oracle Container Registry Mirrors.

  1. Sign in to the Oracle Container Registry.

    In a web browser, sign in to the Oracle Container Registry using an Oracle account at https://container-registry.oracle.com.

  2. Accept the Oracle Standard Terms and Restrictions.

    Accept the Oracle Standard Terms and Restrictions for the Oracle software images you want to pull. Acceptance of these terms are stored in a database that links the software images to an Oracle Account. Acceptance of the Oracle Standard Terms and Restrictions is valid only for the repositories for which you accept the terms. You might need to repeat this process if you try to pull software from other or newer repositories in the registry. Note that Oracle Standard Terms and Restrictions are subject to change without notice.

  3. Find the image.

    Browse or search for Oracle software images in the Oracle Container Registry.

  4. Sign in to the Oracle Container Registry in Podman.

    On the host system, use the podman login command to authenticate against the Oracle Container Registry.

    podman login container-registry.oracle.com

    Provide an Oracle account username, and its associated Oracle Container Registry secret key as the password value, when prompted.

  5. Pull the image.

    Pull the images that you require by using the podman pull command, for example:

    podman pull container-registry.oracle.com/java/serverjre

    The image is pulled from the Oracle Container Registry and stored locally, ready to be used to deploy containers.

  6. Sign out of the Oracle Container Registry in Podman.

    After you have pulled images from the Oracle Container Registry, log out of the registry to prevent unauthorized access and to remove any record of sign in credentials that Podman might store for future operations:

    podman logout container-registry.oracle.com

Generating an Oracle Container Registry Authentication Token

To pull licensed software from the Oracle Container Registry, generate an authentication token and use it as the password value when using the podman login command.

Caution:

From 2025-06-30 onward, authentication tokens are the only accepted credential type when authenticating Podman with the Oracle Container Registry.
  1. Sign in to the Oracle Container Registry.

    In a web browser, sign in to the Oracle Container Registry using an Oracle account at https://container-registry.oracle.com.

  2. Select the profile name.

    Select the profile name, and in the profile menu that appears select Auth Token.

  3. Generate the Secret Key.

    Select Generate Secret Key and note down the secret key. This is only displayed once, during the initial generation.

  4. (Optional) Regenerate the Secret Key.

    If you lose or forget the secret key, generate a new one by selecting Delete Secret Key, then select Generate Secret Key again.

Using Oracle Container Registry Mirrors

The Oracle Container Registry has many mirror servers around the world. You can use a registry mirror in a specific global region to improve download performance of container images.

To list all the available mirrors and the command to use for pulling images from a specific mirror, see the information page for an image on the Oracle Container Registry web interface. The Tags table on the information page includes a Download Mirror drop down list to select a registry mirror. When you select a mirror, the Pull Command column changes to show the command to pull the image from the selected mirror.

To download licensed Oracle software images from a registry mirror, you must first accept the Oracle Standard Terms and Restrictions in the Oracle Container Registry web interface, and sign in to the Oracle Container Registry in Podman. For information on pulling licensed software images, see Pulling Licensed Software From the Oracle Container Registry.

If you use a mirror regularly, add it to the configuration so that the mirror is used by default for searches and pull requests. See Configuring Registries for more information.

Example 13-1 Pull an image from a mirror

Pull the Oracle Linux 9 slim image from the Sydney mirror:

podman pull container-registry-sydney.oracle.com/os/oraclelinux:9-slim

Example 13-2 Pull a licensed image from a mirror

To pull licensed Oracle software images, sign in to the Oracle Container Registry mirror with Oracle SSO username and Oracle Container Registry authentication token as the password before you pull the image. We recommend you sign out of the registry after the image is pulled.

For example, to pull the latest Java Platform, Standard Edition (Java SE) image:

podman login container-registry-sydney.oracle.com
podman pull container-registry-sydney.oracle.com/java/serverjre:latest
podman logout container-registry-sydney.oracle.com.oracle.com

Oracle Linux Container Image Tagging Conventions

Oracle follows several conventions when tagging container images for Oracle Linux. Users should be aware of these conventions to ensure that the best image is used for the purpose at hand to avoid unnecessary breakages in functionality and to help ensure that images continue to use the most recently patched software.

The slim Tag

Oracle releases minimal compressed versions of each Oracle Linux release. These images contain enough of the OS to run within a container and to perform installations of more packages. These images are the recommended images for general use within builds and where scripted installation is likely to be used. The images that use this tag are maintained at the most current update level.

For example, to use the most recent version of an Oracle Linux 9 slim image, use the 9-slim tag. To use the most recent version of an Oracle Linux 10 slim image, use the 10-slim tag.

FIPS compliant versions of images are tagged with the slim-fips tag. These images include compliant cryptographic package versions and most of the initial image setup required for container FIPS compliance. To use these images, you must enable FIPS mode on the host system.

Example 13-3 Pull an Oracle Linux 9 slim image

Pull the most recent version of an Oracle Linux 9 slim image:

podman pull oraclelinux:9-slim
General Oracle Linux Release Tags

Oracle Linux images are tagged at their release level and are maintained to always map to the latest corresponding update level. If you need a more complete OS than the version provided in a slim image, use a release tag to obtain the latest image for that Oracle Linux image.

Example 13-4 Pull the latest Oracle Linux 9 image

Pull the latest update release image for Oracle Linux 9:

podman pull oraclelinux:9
Oracle Linux Update Level Tags

Oracle Linux images are tagged at their update level. The other tags described map onto the latest or most current update level for an Oracle Linux image.

WARNING:

Don't directly use update level tags within a Containerfile or within any builds unless you have a specific use case that requires a particular update level. Typical use cases involve trying to resolve an issue or bug that's only present at a particular update level of Oracle Linux.

Using an update level tag can result in containers running unpatched software that might expose them to security issues and software bugs.

Update level tags use dot notation to indicate the update level. For example, Oracle Linux 8.10 is indicated using the 8.10 tag:

podman pull oraclelinux:8.10
The latest Tag

Important:

Oracle doesn't provide this tag for Oracle Linux images. Use a slim image or a release tag instead. Oracle also recommends that users avoid dependency on this tag when working with other distribution or software images.

The use of a default often results in significant confusion and can break builds and scripted functionality for end users. For this reason, and to help encourage best practice when working with image tags, Oracle doesn't provide a latest tag for Oracle Linux images.

The following reasons for Oracle's decision on this help explain why this tag isn't available:

  • When the latest tag is used, it can result in significant jumps between distribution releases rather than update levels. This is often not what a user intends when selecting the latest tag, or depending on tools to fall back to this tag by not specifying a tag at all. Expected functionality can change dramatically between releases resulting in changes to commands, options, configurations, and available software.

  • No easy way to identify which latest image was used for a particular build exists, making it difficult to see the differences between two final build images. This problem tracking changes also makes it difficult to roll back to a known functioning base image if a new build fails.

  • Tagging an image with the latest tag isn't automatic and it's possible for a more recent image to be available while the image tagged as latest hasn't been updated. This can lead to unexpected consequences.

  • Not all tools treat the latest tag the same. While some tools might default to always pulling an image tagged as latest from an upstream registry, other tools might default to a locally stored image also tagged as latest, even if it has fallen out of date.

This decision might result in errors in some tools that fall back to the latest tag when no tag is specified for an image. For example, the following command returns an error:

podman pull docker.io/library/oraclelinux

The error looks similar to:

Trying to pull docker.io/library/oraclelinux:latest...
Error: initializing source docker://oraclelinux:latest: reading manifest latest in 
docker.io/library/oraclelinux: manifest unknown

Always specify the appropriate tag for the image that you intend to use. For example:

podman pull container-registry.oracle.com/os/oraclelinux:9

Docker Hub

Use the Docker Hub Registry to pull software container images.

The Docker Hub registry provides many software images, primarily for use with Docker but which are compatible with Podman. The Docker Hub registry provides a web interface for browsing available images.

The Docker Hub contains Docker images for licensed commercial Oracle software products that you might use in an enterprise.

To access images hosted in the Docker Hub, you must sign in with a valid Docker account. To get more information about creating a Docker account and using the Docker Hub, see the Docker Hub documentation.

The Docker Hub provides a web interface where you can select the Docker Certified images that you want to install. For some images, you would need to select Proceed to Checkout to either agree to any terms and conditions that might apply or to make payment if required before you can access the image.

At the conclusion of the transaction, the image is stored in the My Content area, which you can revisit later. Each image provides a description and set up instructions.

Use the podman login command to sign in to Docker Hub and pull images. For example:

podman login docker.io
podman pull docker.io/library/alpine:latest
podman logout docker.io

Configuring Podman for Signed Images

Set up Podman to pull images that are signed by a validated public key for a container registry. Any unsigned images can't be pulled.

You can configure Podman to only trust images from a remote registry if they're signed and the provided signature can be validated against a locally stored public key. This configuration option can help improve security and can mitigate against inadvertently running a compromised image.

Images are signed in a similar way to packages that are made available on the Oracle Linux yum server. GPG keys are used to sign images provided at the registry. The digital signatures for each image are stored in a signature store that's accessible by using HTTPS. A public GPG key that's used to validate the signature against the image digest must be available on the system where Podman is installed.

The following steps describe how to configure a Podman host to require that images from a remote registry are signed and validated before they can be used locally.

  1. Create a registry configuration file.

    For each registry where you require signature validation, create a YAML format configuration file in the /etc/containers/registries.d/ directory (or in $HOME/.config/containers/registries.d/ directory for standard users) and provide the value for the sigstore for that registry.

    For example, for the Oracle Container Registry, create the /etc/containers/registries.d/oracle.yaml file and populate it with the following content:

    docker:
      container-registry.oracle.com:
        sigstore: https://container-trust.oci.oraclecloud.com/podman

    See /etc/containers/registries.d/default.yaml for more information and to view a template configuration.

  2. Download the public GPG key.

    Download and store the public GPG key that must be used to validate signatures for images from the registry. For the Oracle Container Registry, you can download the public GPG key from https://container-trust.oci.oraclecloud.com/podman/GPG-KEY-oracle. For example:

    sudo mkdir -p /etc/pki/containers
    sudo wget -O /etc/pki/containers/GPG-KEY-oracle https://container-trust.oci.oraclecloud.com/podman/GPG-KEY-oracle
  3. Set the container policy.

    Edit the container policy configuration to add the location of the public GPG key that must be used to validate the signatures for images that are pulled from a particular registry.

    The policy configuration is in JSON format and is at /etc/containers/policy.json. Registry configuration appears under the docker key, which you might need to add under the transports key in the existing configuration. For example, a default policy configuration that has been edited to include an entry for the Oracle Container Registry appears as follows:

    {
      "default": [
        {
          "type": "insecureAcceptAnything"
        }
      ],
      "transports":
        {
          "docker-daemon":
            {
              "": [{"type":"insecureAcceptAnything"}]
            },
          "docker":
            {
              "container-registry.oracle.com": [
                {
                  "type": "signedBy",
                  "keyType": "GPGKeys",
                  "keyPath": "/etc/pki/containers/GPG-KEY-oracle"
                }
              ]
            }
        }
    }

    See the containers-policy.json(5) manual page for more information about the format of this configuration file.

  4. Validate the configuration.

    Validate that the configuration is correct by pulling an image from the remote registry. For example:

    podman pull container-registry.oracle.com/os/oraclelinux:9-slim

    If the signature requirement is configured correctly, the output isn't different from an output when you pull an image without signature validation configured.

  5. (Optional) Confirm GPG key is used.

    You can test that validation is taking place by setting the GPG keyPath in the policy configuration to use another key. For example, you can configure the path to use the GPG key used to validate RPM packages at /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle. When pulling the same image, validation of the signature fails with an error similar to:

    Trying to pull container-registry.oracle.com/os/oraclelinux:9-slim...
    Error: copying system image from manifest list: Source image rejected: Invalid GPG signature: 
    gpgme.Signature{Summary:128, Fingerprint:"4451CA2B13A2D6522D9E12DF357217938FC350A2", 
    Status:gpgme.Error{err:0x9}, Timestamp:time.Date(2025, time.July, 16, 19, 18, 22, 0, time.Local), 
    ExpTimestamp:time.Date(1970, time.January, 1, 0, 0, 0, 0, time.Local), WrongKeyUsage:false, 
    PKATrust:0x0, ChainModel:false, Validity:0, ValidityReason:error(nil), PubkeyAlgo:1, HashAlgo:8}

Configuring Registries

Edit the container registry configuration file to set registry options for the environment. This can be set system wide, and for users.

To configure default registry settings, edit the /etc/containers/registries.conf file, which is in TOML format. The configuration file is commented to explain the options that are available. You can create a user specific registry configuration file by copying the system wide configuration file (/etc/containers/registries.conf) to a user's directory at $HOME/.config/containers/registries.conf. For example:

cp /etc/containers/registries.conf $HOME/.config/containers/registries.conf

For detailed information on all options in the container registries configuration file, see the upstream documentation, or the containers-registries.conf(5) manual page.

Listing Registries

To see the registries configured to use when searching for container images, use:

podman info --format='{{.Registries}}'

The output looks similar to:

map[search:[container-registry.oracle.com docker.io]]

Setting Registry Order

The registries that are searched when you try to pull or use an image that isn't available locally are defined in the following configuration block:
unqualified-search-registries = ["container-registry.oracle.com", "docker.io"]

Registries are searched sequentially in the order that they're defined in this list. If a local registry exists, add it at the beginning of the list to make it the first searched registry.

Adding Registries

To add a registry to Podman, edit the Podman system wide or user configuration file to include the registry in the unqualified-search-registries entry. Add it in the order you want container searches and pulls to be performed. For example:

unqualified-search-registries = ["localhost:5000", "myregistry.example.com:5000", container-registry.oracle.com", "docker.io"]

If the registry is an insecure registry, also edit the [[registry]] section and include the insecure = true option with the registry location.

[[registry]]
location = "localhost:5000"
insecure = true

Adding Insecure Registries

To use an insecure registry without a valid SSL certificate or that doesn't use SSL, edit the [[registry]] section and include the insecure = true option with the registry location. For example:

[[registry]]
location = myregistry.example.com:5000
insecure = true

[[registry]]
location = "localhost:5000"
insecure = true