Harbor Helm Chart: Building Isolated Registries for Customers

Direct answer

Harbor is an open-source, trusted cloud-native registry that stores, signs, and scans container images, Helm charts, and any other OCI-compliant artifacts. The official Harbor Helm chart deploys Harbor on Kubernetes. A release-per-customer model gives each tenant its own Harbor registry with dedicated domains, credentials, storage policies, project isolation, and release lifecycles.

What the Harbor Helm chart provides

The chart installs Harbor components including core, registry, jobservice, database, and Redis. Harbor provides:

Private container and artifact registry with role-based access control
Vulnerability scanning using Trivy or other compatible scanners
Policy-based image replication across registries
Project-based isolation for granular access control
OCI artifact support for Helm charts
Webhook notifications for CI/CD integration

Since version 1.6.0, Harbor supports Helm charts management as a composite, cloud-native registry.

The use case: dedicated container registries per customer

A release-per-customer model is valuable when customers need:

Independent container image and Helm chart storage
Customer-specific domains and TLS
Separate vulnerability scanning and retention policies
Isolated replication and webhook configurations
Controlled storage quotas and lifecycle policies
Clean export, suspension, and deletion boundaries

Harbor's project-based isolation provides logical separation within a shared instance. Dedicated releases add operational separation: independent runtime, storage ownership, credentials, domain, network policy, and maintenance windows.

Reference architecture

customer registry profile
  → validate domain, storage, and retention requirements
  → resolve tenant-scoped database, Redis, and storage secrets
  → render Harbor values for one release
  → install into the tenant namespace
  → verify registry, scanner, and route readiness
  → promote or roll back independently

The chart uses Helm's templating engine to generate Kubernetes manifests from user-provided configuration values. OpenTenant supplies tenant-specific configuration while keeping the base chart versioned.

Illustrative tenant declaration

tenant: acme
userspace:
  namespace: tenant-acme-harbor
  domain: registry.acme.example
deployment:
  engine: helm
  template: harbor
  release: harbor-acme
  config:
    registry:
      storage:
        s3:
          bucket: harbor-acme
          region: us-east-1
    database:
      external:
        host: postgres-acme.svc
        database: harbor
    redis:
      external:
        host: redis-acme.svc
  secretScope: tenants/acme/harbor

This is illustrative. Production Harbor declarations require extensive configuration across all components.

Production decisions before onboarding

Storage topology. Harbor stores images, Helm charts, and other artifacts. Choose S3-compatible object storage, Azure Blob, GCS, or other supported backends. Each tenant needs a dedicated bucket or path with isolated credentials.

Database and Redis. Harbor requires PostgreSQL and Redis. Decide whether each customer receives dedicated service instances, dedicated databases on shared services, or a governed shared topology.

Domain and TLS. Each customer registry needs a unique domain and TLS certificate. Harbor supports external TLS termination through Ingress or Gateway API.

Project isolation. Harbor's project-based isolation provides logical separation within a registry. For stronger boundaries, each release can be configured with its own set of projects, users, and policies.

Retention and replication. Configure per-tenant retention policies for image and chart cleanup. Replication can sync artifacts between customer registries and central repositories.

Vulnerability scanning. Each tenant registry needs scanning configuration. Scanners like Trivy can be configured per release.

Evaluation checklist

Does every tenant have a dedicated storage bucket and credentials?
Are database, Redis, and storage credentials isolated per tenant?
Can one tenant's image pull or push affect another tenant's registry performance?
Are retention and replication policies configured per tenant?
Can you upgrade one tenant, verify it, and stop the rollout?
Does offboarding remove storage, credentials, and runtime resources?
Are vulnerability scans configured and reports retained per tenant?

Sources

OpenTenant transforms Harbor from a single registry into a multi‑tenant registry platform with each customer owning its own domain, storage, and security policies.