Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Registry

Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS can build images from your source code, deploy them, and manage their lifecycle.

Red Hat OpenShift Documentation Team

Abstract

Red Hat OpensShift Service on AWS provides an internal, integrated container image registry that can be deployed in your Red Hat OpenShift Service on AWS environment to locally manage images.

Chapter 1. OpenShift image registry overview
Copy link

Red Hat OpenShift Service on AWS can build images from your source code, deploy them, and manage their lifecycle. Red Hat OpenShift Service on AWS provides an internal, integrated container image registry that can be deployed in your Red Hat OpenShift Service on AWS environment to locally manage images. The overview section includes OpenShift image registry reference information and links for registries commonly used with Red Hat OpenShift Service on AWS.

This glossary defines the common terms that are used in the registry content.

container
Lightweight and executable images that consist of software and all its dependencies. Because containers virtualize the operating system, you can run containers in a data center, a public or private cloud, or your local host.
Image Registry Operator
The Image Registry Operator runs in the CONTROL_PLANE_NAMESPACE of the management cluster, and manages the registry instance in the openshift-image-registry of the cluster.
image repository
An image repository is a collection of related container images and tags identifying images.
mirror registry
The mirror registry is a registry that holds the mirror of Red Hat OpenShift Service on AWS images.
namespace
A namespace isolates groups of resources within a single cluster.
pod
The pod is the smallest logical unit in Kubernetes. A pod consists of one or more containers to run in a compute node.
private registry
A registry is a server that implements the container image registry API. A private registry is a registry that requires authentication so that users can access the content of the registry.
public registry
A registry is a server that implements the container image registry API. A public registry is a registry that serves its content publicly.
Quay.io
A public Red Hat Quay Container Registry instance provided and maintained by Red Hat, which serves most of the container images and Operators to Red Hat OpenShift Service on AWS clusters.
OpenShift image registry
OpenShift image registry is the registry provided by Red Hat OpenShift Service on AWS to manage images.
registry authentication
To push and pull images to and from private image repositories, the registry needs to authenticate its users with credentials.
route
Exposes a service to allow for network access to pods from users and applications outside the Red Hat OpenShift Service on AWS instance.
scale down
To decrease the number of replicas.
scale up
To increase the number of replicas.
service
A service exposes a running application on a set of pods.

1.2. Integrated OpenShift image registry
Copy link

Red Hat OpenShift Service on AWS provides a built-in container image registry that runs as a standard workload on the cluster. The registry is configured and managed by an infrastructure Operator. The registry provides an out-of-the-box solution that runs on top of existing cluster infrastructure, so that you can manage the images that run workloads.

You can scale the registry up or down like any other cluster workload and the registry does not require specific infrastructure provisioning. The registry also integrates into the cluster user authentication and authorization system, which means that defining user permissions on image resources controls access to create and retrieve images.

The registry is typically used as a publication target for images built on the cluster and as a source of images for workloads running on the cluster. When you push a new image to the registry, a notification gets sent to the cluster of the new image so that other components can react to and consume the updated image.

Image data is stored in two locations. The actual image data is stored in a configurable storage location, such as cloud storage or a filesystem volume. The image metadata, which is exposed by the standard cluster APIs and is used to perform access control, is stored as standard API resources, specifically images and image streams.

1.3. Automatically pruning images
Copy link

Images from the OpenShift image registry that are no longer required by the system because of age, status, or exceed limits being automatically pruned. As a cluster administrator, can configure or suspend the pruning Custom Resource (CR).

Prerequisites

  • You have access to an Red Hat OpenShift Service on AWS cluster using an account with dedicated-admin permissions.
  • Install the oc CLI.
Important

The behavior of the Image Registry Operator for managing the pruner is independent to the managementState specified on the ClusterOperator object of the Image Registry Operator. If the Image Registry Operator is not in the Managed state, the image pruner can still be configured and managed by the Pruning Custom Resource.

However, the managementState of the Image Registry Operator alters the behavior of the deployed image pruner job:

  • Managed: the --prune-registry flag for the image pruner is set to true.
  • Removed: the --prune-registry flag for the image pruner is set to false, meaning it only prunes image metadata in etcd.

Procedure

  • Verify that the object named imagepruners.imageregistry.operator.openshift.io/cluster contains the following spec and status fields: 

    spec:
  schedule: 0 0 * * *
  suspend: false
  keepTagRevisions: 3
  keepYoungerThanDuration: 60m
  keepYoungerThan: 3600000000000
  resources: {}
  affinity: {}
  nodeSelector: {}
  tolerations: []
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
status:
  observedGeneration: 2
  conditions:
  - type: Available
    status: "True"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Ready
    message: "Periodic image pruner has been created."
  - type: Scheduled
    status: "True"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Scheduled
    message: "Image pruner job has been scheduled."
  - type: Failed
    staus: "False"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Succeeded
    message: "Most recent image pruning job succeeded."
    Copy to Clipboard Toggle word wrap
  • schedule: CronJob formatted schedule. This is an optional field, default is daily at midnight.
  • suspend: If set to true, the CronJob running pruning is suspended. This is an optional field, default is false. The initial value on new clusters is false.
  • keepTagRevisions: The number of revisions per tag to keep. This is an optional field, default is 3. The initial value is 3.
  • keepYoungerThanDuration: Retain images younger than this duration. This is an optional field. If a value is not specified, either keepYoungerThan or the default value 60m (60 minutes) is used.
  • keepYoungerThan: Deprecated. The same as keepYoungerThanDuration, but the duration is specified as an integer in nanoseconds. This is an optional field. When keepYoungerThanDuration is set, this field is ignored.
  • resources: Standard pod resource requests and limits. This is an optional field.
  • affinity: Standard pod affinity. This is an optional field.
  • nodeSelector: Standard pod node selector. This is an optional field.
  • tolerations: Standard pod tolerations. This is an optional field.
  • successfulJobsHistoryLimit: The maximum number of successful jobs to retain. Must be greater than or equal to 1 to ensure metrics are reported. This is an optional field, default is 3. The initial value is 3.
  • failedJobsHistoryLimit: The maximum number of failed jobs to retain. Must be greater than or equal 1 to ensure metrics are reported. This is an optional field, default is 3. The initial value is 3.
  • observedGeneration: The generation observed by the Operator.

  • conditions: The standard condition objects with the following types:

    • Available: Indicates if the pruning job has been created. Reasons can be Ready or Error.
    • Scheduled: Indicates if the next pruning job has been scheduled. Reasons can be Scheduled, Suspended, or Error.
    • Failed: Indicates if the most recent pruning job failed.

Some container image registries require access authorization. Podman is an open source tool for managing containers and container images and interacting with image registries. You can use Podman to authenticate your credentials, pull the registry image, and store local images in a local file system. The procedure provides a generic example of authenticating the registry with Podman.

Red Hat OpenShift Service on AWS can communicate with registries to access private image repositories by using credentials supplied by the user. This allows Red Hat OpenShift Service on AWS to push and pull images to and from private repositories.

Red Hat OpenShift Service on AWS can create containers by using images from third-party registries, but these registries unlikely offer the same image notification support as the integrated OpenShift image registry.In this situation, Red Hat OpenShift Service on AWS fetches tags from the remote registry upon image stream creation. To refresh the fetched tags, run oc import-image <stream>. When new images are detected, the previously described build and deployment reactions occur.

Procedure

  1. Use the Red Hat Ecosystem Catalog to search for specific container images from the Red Hat Repository and select the required image.
  2. Click Get this image to find the command for your container image.

  3. Log in by running the following command and entering your username and password to authenticate. Example output is shown for demonstrative purposes. 

    $ podman login registry.redhat.io
    Copy to Clipboard Toggle word wrap 
     Username:<your_registry_account_username>
 Password:<your_registry_account_password>
    Copy to Clipboard Toggle word wrap

  4. Download the image and save it locally by running the following command: 

    $ podman pull registry.redhat.io/<repository_name>
    Copy to Clipboard Toggle word wrap

1.5. Red Hat Quay registries
Copy link

If you need an enterprise-quality container image registry, Red Hat Quay is available both as a hosted service and as software that you can install in your own data center or cloud environment. Advanced features in Red Hat Quay include geo-replication, image scanning, and the ability to roll back images.

Visit the Quay.io site to set up your own hosted Quay registry account. After that, follow the Quay Tutorial to log in to the Quay registry and start managing your images.

You can access your Red Hat Quay registry from Red Hat OpenShift Service on AWS, similar to any remote container image registry.

1.6. Authentication enabled Red Hat registry
Copy link

All container images available through the Container images section of the Red Hat Ecosystem Catalog are hosted on an image registry, registry.redhat.io. The registry, registry.redhat.io, requires authentication for access to images and hosted content on Red Hat OpenShift Service on AWS.

Note

Red Hat OpenShift Service on AWS pulls images from registry.redhat.io, so you must configure your cluster to use it.

The new registry uses standard OAuth mechanisms for authentication, with the following methods:

  • Authentication token. Tokens, which are generated by administrators, are service accounts that give systems the ability to authenticate against the container image registry. Service accounts are not affected by changes in user accounts, so the token authentication method is reliable and resilient. This is the only supported authentication option for production clusters.
  • Web username and password. This is the standard set of credentials you use to log in to resources such as access.redhat.com. While you could use this authentication method with Red Hat OpenShift Service on AWS, Red Hat does not support the method for production deployments. Restrict this authentication method to standalone projects outside Red Hat OpenShift Service on AWS.

You can use podman login with your credentials, either username and password or authentication token, to access content on the new registry.

All image streams point to the new registry, which uses the installation pull secret to authenticate.

You must place your credentials in either of the following places:

  • openshift namespace. Your credentials must exist in the openshift namespace so that the image streams in the openshift namespace can import.
  • Your host. Your credentials must exist on your host because Kubernetes uses the credentials from your host when it goes to pull images.

The Image Registry Operator installs a single instance of the OpenShift image registry and manages all registry configuration, including setting up registry storage.

After the control plane deploys in the management cluster, the Operator creates a default configs.imageregistry.operator.openshift.io custom resource (CR) instance based on configuration detected in the cluster.

If insufficient information is available to define a complete configs.imageregistry.operator.openshift.io CR, the incomplete resource is defined and the Operator updates the resource status with information about what is missing.

The Image Registry Operator runs in the CONTROL_PLANE_NAMESPACE environment variable of the management cluster, and manages the registry instance in the openshift-image-registry namespace of the cluster. All configuration and workload resources for the registry reside in that namespace.

Chapter 3. Accessing the registry
Copy link

In Red Hat OpenShift Service on AWS, Red Hat Site Reliability Engineering (SRE) manages the registry for you. However, you can check the status of the registry pods and view the registry logs.

3.1. Checking the status of the registry pods
Copy link

As an administrator with the dedicated-admin role, you can list the image registry pods running in the openshift-image-registry project and check their status.

Prerequisites

  • You have access to the cluster as a user with the dedicated-admin role.

Procedure

  • List the pods in the openshift-image-registry project and view their status. Example output provided for demonstrative purposes. 

    $ oc get pods -n openshift-image-registry
    Copy to Clipboard Toggle word wrap 
    NAME READY STATUS RESTARTS AGE
image-registry-79fb4469f6-llrln 1/1 Running 0 77m
node-ca-hjksc 1/1 Running 0 73m
node-ca-tftj6 1/1 Running 0 77m
node-ca-wb6ht 1/1 Running 0 77m
node-ca-zvt9q 1/1 Running 0 74m
    Copy to Clipboard Toggle word wrap

3.2. Viewing registry logs
Copy link

You can view the logs for the registry by using the oc logs command.

Procedure

  • Use the oc logs command with deployments to view the logs for the container image registry. Example output provided for demonstrative purposes. 

    $ oc logs deployments/image-registry -n openshift-image-registry
    Copy to Clipboard Toggle word wrap 
    2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown"
2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler"
2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
    Copy to Clipboard Toggle word wrap

Legal Notice
Copy link

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

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

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

Theme

© 2025 Red Hat