What Is The Default Registry In OpenShift?

The default registry in OpenShift is the OpenShift Internal Image Registry, an integrated container image registry that runs within the cluster as a standard workload. It is automatically managed by the Image Registry Operator and serves as the primary location for storing and managing container images built or deployed on the platform.

Deep dive into the OpenShift Internal Registry

The Image Registry Operator

The OpenShift Internal Image Registry is not a standalone application that requires manual setup; it is managed by the Image Registry Operator, a built-in infrastructure Operator.

• Singleton Instance: The operator ensures there is a single instance of the registry, located in the openshift-image-registry namespace.
• Automatic Configuration: On initial startup, the Operator detects the cluster's infrastructure (e.g., cloud provider, storage availability) and creates a default registry configuration resource (configs.imageregistry.operator.openshift.io).
• Self-Healing: If configuration details are missing, the Operator creates an incomplete resource and reports the missing information in its status, allowing administrators to address the issue.
• Management State: The Operator can be set to different management states:
  • Managed: The default state where the Operator actively manages the registry based on the configuration resource.
  • Unmanaged: The Operator ignores any changes to the configuration.
  • Removed: The Operator tears down the registry instance and any storage it provisioned.

Image storage

The registry's image data is stored in a configurable storage backend, while the image metadata is stored as standard OpenShift API resources like Image and ImageStream.

• Installer-Provisioned Infrastructure: For clusters on public clouds like AWS, GCP, or Azure, the storage is automatically configured using the cloud provider's object storage (e.g., S3 buckets).
• Bare Metal and vSphere: On platforms that do not provide automated object storage, the registry is initially set to Removed. Administrators must manually configure a storage backend, such as persistent storage via a PersistentVolume.
• Storage Configuration: The storage details are defined in the configs.imageregistry.operator.openshift.io/cluster resource. This allows for fine-tuning the storage, such as specifying a custom S3 bucket and region or configuring encryption.

Registry security and access control

OpenShift's internal registry is integrated with the cluster's built-in authentication and authorization systems, providing secure access.

• Internal Access: By default, the registry is accessible within the cluster via an internal service IP address. Pods pulling images from the internal registry do not require special credentials, as OpenShift manages the required authentication automatically via service accounts.
• External Access (Routes): For external access, such as pushing images from a local system, administrators must expose the registry via an OpenShift Route.
  • The defaultRoute parameter in the registry configuration can be set to true to automatically create a re-encrypt TLS route.
  • Authentication for external access typically uses an OpenShift access token, which can be retrieved with oc whoami -t.

Image Streams and the registry

The OpenShift Internal Registry is most commonly interacted with indirectly via the ImageStream resource.

• Centralized Metadata: An ImageStream provides a single point of reference for an image, including its history, tags, and security information.
• Workflow:
  1. An application is built using a Build Config, which pushes the resulting image to the internal registry.
  2. This action automatically updates the associated ImageStream.
  3. A Deployment Config or Deployment can reference this ImageStream and automatically redeploy when a new image version (tag) is available.
• Separation of Concerns: This approach decouples image metadata (the ImageStream) from the image binary (in the registry), providing a more flexible and secure image management workflow.

Integrating with external registries

While the internal registry is the default, OpenShift can also seamlessly integrate with external registries like Red Hat Quay or Docker Hub.

• Trusted CAs: For private external registries, a cluster administrator can configure additional Certificate Authority (CA) trust stores to allow the cluster to securely pull images.
• Image Sources: The Image.config.openshift.io resource allows administrators to define a prioritized list of registries for image pull actions, enabling the use of short names (e.g., ubi8 instead of registry.redhat.io/ubi8).