Skip to content

Harbor

Harbor is a container registry. This package wraps the Harbor Helm chart v1.19.2 and supplies Big Bang integration for routing, service mesh, network policies, monitoring, PostgreSQL, Redis, OpenShift, and package tests.

For Harbor product behavior, administration, high availability, and the full configuration surface, use the Harbor documentation and the version-matched upstream values.

Configure through Big Bang

Enable the package through the canonical packages.harbor entry. The legacy addons.harbor path remains compatible. Big Bang passes package-specific chart values under packages.harbor.values (or addons.harbor.values for the legacy path):

packages:
  harbor:
    enabled: true
    values: {}

The package’s upstream value is the parent passthrough for the upstream Harbor chart. Configure upstream Harbor options below that parent and consult the upstream values file for supported keys and defaults. Big Bang supplies selected image, security, monitoring, and registry integration overrides; do not copy upstream defaults into an overlay unless an override is needed.

Routing and access

Big Bang sets Harbor’s external URL to https://harbor.<domain> and creates an inbound route through the selected Istio gateway. Set the Big Bang domain and, when necessary, select a different gateway with packages.harbor.ingress.gateway. The route sends Harbor API, token, chart, and registry (/v2/) requests to the core service and sends other requests to the portal service.

Harbor authentication, robot accounts, projects, and registry client configuration are Harbor-managed. Keep administrator, robot-account, database, Redis, object-storage, and TLS material in Kubernetes Secrets; reference existing Secrets through the appropriate upstream Harbor values rather than placing credentials in an overlay or repository. If configuring OIDC, use the current Harbor OIDC documentation.

Storage and dependencies

The chart enables its PostgreSQL and Big Bang Redis dependencies by default and configures Harbor to use them as external services. A deployment can instead use external PostgreSQL or Redis, but the related endpoint, credentials, and network access must be configured together. When an external Redis address is supplied, the umbrella adds the corresponding mesh route and network-policy destination.

For example, these package values select an existing TLS-enabled Redis endpoint and credentials Secret:

redis-bb:
  enabled: false
upstream:
  redis:
    type: external
    external:
      addr: redis.example.com:6379
      existingSecret: harbor-redis
      tlsOptions:
        enable: true

Provision harbor-redis in the Harbor namespace with key REDIS_PASSWORD; an ACL user also needs REDIS_USERNAME. Match the actual port and provider’s supported database indexes. The locked chart resolves this Redis Secret with Helm lookup during rendering: it must already exist and the renderer must have permission to read it. Offline helm template does not verify that lookup or authentication. For a private Redis CA, provision a Secret containing ca.crt and reference it through upstream.caBundleSecretName. This is Redis server-authenticated TLS, not mutual TLS. Supply corresponding outbound mesh registration and narrow NetworkPolicy rules separately; setting addr alone does not grant access. Disabling bundled Redis does not migrate its state, and a standalone render does not validate cloud Redis compatibility or failover.

Registry persistence is configured through upstream.persistence. Choose and operate filesystem or object storage according to the Harbor persistence documentation. Storage, TLS, project layout, and recovery planning are availability concerns: Harbor may serve image pulls for other cluster workloads. See the Big Bang Harbor storage guidance for cross-package considerations.

For example, these package values select an existing S3-compatible bucket and Secret rather than placing storage credentials in the overlay:

upstream:
  persistence:
    enabled: true
    imageChartStorage:
      type: s3
      disableredirect: true
      s3:
        region: us-east-1
        regionendpoint: https://objects.example.com
        bucket: harbor-artifacts
        existingSecret: harbor-registry-s3
        secure: true
        skipverify: false

Provision the bucket and harbor-registry-s3 Secret in the Harbor namespace through approved workflows. The Secret keys must be REGISTRY_STORAGE_S3_ACCESSKEY and REGISTRY_STORAGE_S3_SECRETKEY. Replace the endpoint, region, and bucket with actual provider settings and narrowly scoped credentials. For a private storage CA, set upstream.persistence.imageChartStorage.caBundleSecretName to an existing Secret containing ca.crt; do not bypass certificate verification. This example keeps redirects disabled so registry clients need not access the object store directly; review provider and performance requirements before choosing another redirect policy. It does not configure database/cache persistence, network access, backup, or artifact migration. Switching a live registry’s storage backend does not copy its existing artifacts: plan and test migration and recovery before the change.

Mesh, network policy, and monitoring

When Istio egress is restricted, enabling the package’s Istio and network-policy integration permits the Harbor Trivy workload to retrieve vulnerability database artifacts from ghcr.io and mirror.gcr.io over TLS. The policy is scoped to Trivy and excludes the instance metadata endpoint. Review Istio hardening and network policy configuration before adding routes or policies for other external services.

When Big Bang monitoring is enabled, the package enables Harbor metrics and its ServiceMonitor and supplies a Grafana dashboard. The umbrella also applies a ServiceMonitor TLS post-renderer for sidecar mode; the umbrella owns that post-renderer and package dependency ordering.

Operations

  • Use Harbor’s upgrade guide for product upgrade prerequisites. Package releases also require the usual Big Bang package upgrade review.
  • The package’s deployed tests exercise portal login, project creation and deletion, and registry push/pull behavior. They require a disposable test environment and are not run as local documentation validation.
  • Review production guidance and package branch testing before performing a production, storage, or cross-repository change.