Private registries — Harbor, Quay, and on-prem control

Private container registries provide on-prem control of images, vulnerability scanning, signing, and replication. This lesson walks Harbor, Quay, distribution, and the discipline.

Harbor

flowchart LR
    A[Harbor] --> B["Image storage: S3 / Azure Blob / GCS"]
    A --> C["Vulnerability scanner: Trivy"]
    A --> D["Image signing: cosign"]
    A --> E[Replication rules]
    A --> F[Pull-through cache]
    G[Kubernetes cluster] -->|pull| A

Harbor’s components:

• Image storage. Pluggable; S3, Azure Blob, GCS, local filesystem.
• Vulnerability scanner. Trivy (default), Clair, Anchore.
• Image signing. cosign (Sigstore) integration.
• Replication rules. Replicate images to other registries.
• Pull-through cache. Cache images from upstream (Docker Hub, cloud registries).

Harbor is CNCF Graduated; it is the standard for production on-prem registries.

A project in Harbor

# Create a project
harbor-cli project create \
  --name prod-app \
  --public false \
  --storage-quota 100GB

# Add a user as project admin
harbor-cli user create \
  --username ci-bot \
  --password *** \
  --email ci@example.com

harbor-cli project-member create \
  --project prod-app \
  --user ci-bot \
  --role project-admin

The project:

• Storage quota. Limits the project’s storage.
• Public/private. Private by default.
• Members. Users with project-level roles.

The CI/CD pipeline pushes images to the project using the CI bot’s credentials.

Vulnerability scanning

flowchart LR
    A[Image pushed] --> B["Harbor: trigger scan"]
    B --> C["Trivy: scan layers"]
    C --> D{Vulnerabilities found?}
    D -->|Yes| E["Report: critical, high, medium, low"]
    D -->|No| F[Mark as clean]
    E --> G[Block deployment if critical]
    F --> H[Allow deployment]

Harbor scans every pushed image. The scan produces a vulnerability report (CVE counts by severity).

Policies can block deployment of images with critical vulnerabilities. CI/CD pipelines fail; the team must remediate.

Image signing with cosign

# Sign an image after pushing
cosign sign --key cosign.key registry.example.com/prod-app/myapp:1.2.3

# Verify a signature
cosign verify --key cosign.pub registry.example.com/prod-app/myapp:1.2.3

cosign integration:

• Sign. After pushing, cosign signs the image.
• Verify. Before deploying, cosign verifies the signature.

Harbor stores the signature alongside the image. Kubernetes can verify via Kyverno or Connaisseur.

Replication

# Create a replication rule
harbor-cli replication create \
  --name prod-to-dr \
  --source-registry local \
  --destination-registry dr-harbor \
  --trigger manual \
  --projects prod-app

Replication rules:

• Source. The local Harbor registry.
• Destination. A remote Harbor (DR site, another cluster).
• Trigger. Manual, scheduled, or event-based.
• Projects. Which projects to replicate.

Replication provides DR (the DR registry has the images) and multi-cluster (multiple clusters pull from the closest registry).

Quay and distribution

Harbor and Quay are both production-ready. Harbor is more popular (CNCF Graduated). distribution is minimal (no scanning, no UI); use it for simple registries.

Quiz

The operational discipline

Private registries in production rest on five non-negotiable elements:

• Harbor for on-prem production. CNCF Graduated; full-featured.
• Enable vulnerability scanning. Block critical vulnerabilities.
• Sign images with cosign. Verify before deployment.
• Replicate to DR. Multi-cluster and DR.
• Back up the registry. Images, signatures, scan reports.

Private registries are the source of application code. The discipline is enable scanning, sign images, and replicate for DR.