Full Package

Full package

4 minute read

The full-package distribution is a self-contained package ready to be deployed in any Kubernetes cluster with available persistent volumes.


To run this project in your Cluster you should understand every component and its configuration parameters. This is the reason why SIGHUP provides a usage example available in the git repository where the module is hosted.

This distribution deploys the following components:

  • portal: Harbor Frontend.
  • core: Harbor main API.
  • jobservice: Event worker.
  • registry: Docker registry. Used to store container images.
  • chartmuseum: Chart registry. Used to store Helm charts.
  • clair: Vulnerability Scanner.
  • notary: Notary server. Signs and verifies container image signatures.
  • redis: Used both for caching and as an event bus.
  • database: Postgresql database ready to use from some components (clair, notary and core).


This distribution was designed to deploy Harbor with a couple of public-facing domains as it requires to expose https services (required to run Notary).

Notary component also requires to create some CA and certificates to sign and verify container image signatures.

Because of these constraints, is required to have previously deployed an ingress controller and cert-manager.


This distribution relies on local volumes to store container images, charts and database files. So you have to provide a default storage class to create the required claims and volumes in the cluster.

Components that require volumes are:

  • Database: Default size: 1Gi
  • Redis: Default size: 1Gi
  • Chartmuseum: Default size: 5Gi
  • Registry: Default size: 5Gi

Make sure you patch default values with your values. Take a look to the example to understand how to do it.


There are a huge number of variables that can be customized in a Harbor deployment. In this section, we will expose some of them. If you want to know all the available variables that can be customized, please refer to the official documentation site

External URL

There are mainly two different external URLs. One for Harbor and the other one for the notary server. To deploy your registry with your own domain name please replace %YOUR_DOMAIN% in the following files with your domain name:


For example, if you want to use example.com as %YOUR_DOMAIN% you will end up with: harbor.example.com and notary.example.com.

Run behind a proxy

If you plan to run this module in an environment where access to the Internet should be configured to pass through a proxy, you should set up some variables to make Harbor working:


Configure with your values:

  • NO_PROXY=core,jobservice,database,chartmuseum,clair,notary-server,notary-signer,registry,portal,,localhost,.local,.internal

These configuration appears more than once in the examples/full-harbor/kustomization.yaml file.

Make sure to don’t proxy internal component requests. The default NO_PROXY value is already configured to avoid it.

Database configuration

This distribution includes a Postgres server to host databases to some Harbor components. The provided example exposes some variables that can be customized to make this Postgres instance secure enough.

But, due to some Kustomize limitation, you will have to modify more than a couple of lines in a file. To successfully customize the default username postgres and password changeit of the database change:

at examples/full-harbor/kustomization.yaml:

  • POSTGRES_USER=postgres

With your secured values.

Once modified you will need to find and replace these values across all the example project:


Note that you will find this values more than once per file

If you have an external Postgres instance, you should take a look at the External DB distribution.


Some secrets should be changed to make this deployment secure. Don’t forget to change:

  • HARBOR_ADMIN_PASSWORD: Default value: Harbor12345. You can find it in the examples/full-harbor/kustomization.yaml file. This is the admin harbor password.
  • secretKey: Part of the core secrets. Used to encrypt http sessions (cookies).
  • secret: Part of the core secrets. Used to establish a symmetric password between components.
  • REGISTRY_HTTP_SECRET: Part of the registry secrets. Used to encrypt HTTP sessions (cookies).
  • secret: Part of the jobservice secrets. Used to establish a symmetric password between components.

This distribution requires some set of TLS certificates:

  • HTTPS: Certificates to expose Harbor and notary with https
    • These certificates are requested using cert-manager with a customizable cluster-issuer.
  • Core: The core component is responsible for generating tokens to secure communication between components.
    • A CA certificate and some certificates are issued with cert-manager (self-signed).
  • Notary Signer: Notary requires to have a CA to sign and verify container images.
    • A CA certificate and some certificates are issued with cert-manager (self-signed).

Take a look to the examples/full-harbor/patch/ingress.yml to see how to override the default issuer for the HTTPS certificate