Container registries

What Is a Container Registry?

A container registry is a service for storing, managing, and distributing container images. It plays a similar role to a “package repository” (like yum or apt), but for container images instead of OS packages.

At a high level, a registry provides:

• A storage backend for container images
• An API to push, pull, and manage images
• Features for access control, scanning, and lifecycle management

In OpenShift and Kubernetes-based environments, virtually all workloads depend on one or more registries as the source of their images.

Registry vs Repository vs Image

These terms are related but distinct:

• Registry – The service endpoint that implements the container registry API.
  Examples:
• docker.io
• quay.io
• registry.redhat.io
• gcr.io, ghcr.io, etc.
• (Image) Repository – A named collection of related images within a registry, usually representing one application or component.
  Examples:
• docker.io/library/nginx
• quay.io/my-org/my-app
• registry.redhat.io/openshift4/ose-cli
• Image – A specific, immutable artifact identified by a tag or a digest within a repository.
  Examples:
• quay.io/my-org/my-app:1.0
• docker.io/library/redis:7
• docker.io/library/redis@sha256:...

An image reference generally has the form:

$$
\texttt{[registry/]namespace/repository[:tag]|[@digest]}
$$

For example:

• docker.io/library/nginx:latest
• quay.io/myteam/api-service:2.3.1
• registry.example.com/analytics/worker@sha256:abcdef...

Types of Container Registries

Public Registries

These are accessible over the internet and often host open-source or publicly available images.

Common public registries:

• Docker Hub (docker.io)
• Historically the default for Docker.
• Hosts official images (e.g., library/nginx, library/postgres).
• Quay.io
• Popular in the Red Hat/OpenShift ecosystem.
• Strong features for security scanning and automation.
• GHCR (ghcr.io)
• GitHub Container Registry, often used to store images alongside code.

Public registries are convenient for:

• Quickly getting base images (e.g., ubuntu, alpine, node, python).
• Sharing open-source applications.

However, they raise considerations around:

• Security and trust (who built the image, how is it updated?).
• Availability and rate limits.
• Compliance (whether external registries are allowed by company policy).

Private Registries

Private registries are controlled by an organization and usually restricted to internal users and systems.

Examples:

• Enterprise-hosted:
• Quay Enterprise / Red Hat Quay
• Harbor
• JFrog Artifactory (Docker registry support)
• Cloud provider registries:
• Amazon ECR
• Google Artifact Registry / GCR
• Azure Container Registry (ACR)

Reasons to use private registries:

• Control over who can push and pull images.
• Ability to enforce security policies and scanning.
• Better performance and reliability within the organization network.
• Storing proprietary or internal applications that must not be public.

Built-In and Cluster-Local Registries

OpenShift includes an integrated image registry service that:

• Runs inside the cluster.
• Stores application images close to where they run, often using cluster storage.
• Integrates with cluster authentication and policies.

Cluster-local registries are especially useful for:

• CI/CD workflows that build images inside the cluster.
• Reducing dependency on external networks.
• Storing intermediate or environment-specific images.

How Registries Store Images (Conceptual)

While the details are abstracted away from end users, some key ideas:

• Layers: Container images are built as a stack of layers. Registries store these layers and re-use them across images to save space and bandwidth.
• Content-addressable storage: Each layer is identified by a digest (e.g., sha256:...), ensuring integrity.
• Manifests: A manifest describes which layers and configuration make up a given image tag.

When you push an image:

1. The client sends the manifest and layers.
2. The registry checks which layers it already has.
3. Only missing layers are uploaded.
4. The registry associates the tag (:1.0, :latest, etc.) with the manifest.

When you pull an image, the registry:

1. Returns the manifest for the tag.
2. The client downloads the required layers.
3. The client assembles the image locally.

Authentication, Authorization, and Access Control

Most non-public registries require authentication. Common mechanisms:

• Username/password
• Tokens (e.g., OAuth tokens, registry-specific tokens)
• Cloud provider identities (IAM roles, service principals)
• Robot/service accounts (for CI/CD pipelines)

Authorization usually controls:

• Who can push (publish new or updated image versions).
• Who can pull (use images in deployments).
• Who can manage repositories (delete images, configure policies).

In automated environments (like OpenShift clusters):

• Pull secrets are provided to nodes/pods to allow pulling from private registries.
• Build pipelines use special service account credentials to push images into a registry.

Image Tags and Versioning

Tags act as human-friendly labels for specific image versions.

Common practices:

• Semantic versioning:
• my-app:1.2.3
• my-app:1.2, my-app:1, my-app:latest
• Build identifiers:
• my-app:build-20241214-01
• my-app:git-abc1234
• Environment-specific tags:
• my-app:dev, my-app:test, my-app:prod (less favored nowadays; GitOps often prefers immutable, digest-based references)

Important behaviors:

• Tags are mutable: my-app:latest can point to different images over time.
• Digests are immutable: my-app@sha256:... always refers to the same content.

For reliability and reproducibility:

• Production and critical workloads often pin to digests rather than tags.
• CI/CD workflows frequently update tags but verify and promote images based on digest.

Basic Push and Pull Workflow (Conceptual)

While specific commands and tools are covered elsewhere, the general workflow with any registry is:

1. Login (if required): authenticate to the registry.
2. Tag a local image with the target registry and repository:
• my-app:1.0 → registry.example.com/project/my-app:1.0
3. Push the image:
• The registry receives layers and manifest.
4. Pull the image from another environment (e.g., OpenShift cluster):
• Workloads reference registry.example.com/project/my-app:1.0 in their configuration.

In OpenShift:

• Build processes (e.g., S2I or Dockerfile builds) often push directly into the cluster’s internal registry.
• Deployments then pull images from this internal registry using service account permissions.

Security and Compliance Aspects of Registries

Container registries are a central point for security and governance:

• Vulnerability scanning
• Automatically scan images when pushed.
• Identify vulnerable packages or libraries.
• Signing and verification
• Use image signing (e.g., Sigstore/cosign, Notary) so consumers can verify image origin and integrity.
• Access control and audit logs
• Track who pushed what and when.
• Enforce least-privilege access to repositories.
• Registry policies
• Restrict use of unscanned or unsigned images.
• Whitelist/blacklist specific registries or repositories.

Organizations usually define policies such as:

• Only allow pulling images from approved registries.
• Require that all production images come from a trusted internal registry after being scanned and approved.
• Regularly clean up old and unused images.

Image Lifecycle and Cleanup

Registries can accumulate many image versions over time. Common lifecycle management practices:

• Retention policies
• Keep only the last N tags or images per repository.
• Keep images used in active deployments; delete older unused ones.
• Garbage collection
• Remove unreferenced layers and manifests to free space.
• Promotion workflows
• Use separate repositories or namespaces for dev/test/prod.
• Promote images between them rather than rebuilding.

In a typical pipeline:

1. Image built and pushed to registry.example.com/dev/my-app:1.0.
2. After tests pass, copy/promote to registry.example.com/stage/my-app:1.0.
3. Once approved, promote to registry.example.com/prod/my-app:1.0.

Registry Integration in Cloud-Native and OpenShift Environments

In cloud-native architectures, registries are deeply integrated into:

• Build pipelines
• Output of a build is an image pushed to a registry.
• Deployment systems
• OpenShift and Kubernetes workloads reference registry images by URL.
• Rolling updates often correspond to pulling a new image tag.
• Policy and governance
• Admission controllers and policies can enforce which registries and images are allowed.
• Hybrid and multi-cluster setups
• Images may be replicated between registries in different regions or clusters to reduce latency and improve availability.

In OpenShift specifically, common patterns include:

• Using the internal OpenShift registry for cluster-local builds and deployments.
• Mirroring or synchronizing images from external registries into an internal, trusted registry.
• Configuring pull secrets and policies so that workloads seamlessly pull the right images from the right registry.

Summary

Container registries are the backbone of container-based workflows:

• They store and distribute images, organizing them into repositories within registries.
• They manage authentication, authorization, and integration with CI/CD and runtime environments.
• They are key control points for security, compliance, performance, and lifecycle management in cloud-native and OpenShift-based platforms.