bitnamicharts/harbor repository overview

⁠Bitnami Secure Images Helm chart for Harbor

Harbor is an open source trusted cloud-native registry to store, sign, and scan content. It adds functionalities like security, identity, and management to the open source Docker distribution.

Overview of Harbor⁠

⁠ TL;DR

helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/harbor

⁠ Introduction

This Helm⁠ chart installs Harbor⁠ in a Kubernetes cluster.

This Helm chart has been developed based on goharbor/harbor-helm⁠ chart but includes some features common to the Bitnami chart library. For example, the following changes have been introduced:

• You can pull all required images from a private registry using the global Docker image parameters.
• Redis® and PostgreSQL are managed as chart dependencies.
• Liveness and Readiness probes for all deployments are exposed to the values.yaml.
• Uses new Helm chart label formatting.
• Uses Bitnami non-root container images by default.
• This chart supports the Harbor optional components.

⁠ Before you begin

• Kubernetes 1.23+
• Helm 3.8.0+
• PV provisioner support in the underlying infrastructure

⁠ Installing the chart

To install the chart with the release name my-release:

helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/harbor

⁠ Configuration and installation details

This section covers resource requests, exposure, TLS, backup, and other options.

⁠ Resource requests and limits

Bitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the resources value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.

To make this process easier, the chart contains the resourcesPreset values, which automatically sets the resources section according to different presets. Check these presets in the bitnami/common chart⁠. However, in production workloads using resourcesPreset is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the official Kubernetes documentation⁠.

⁠ Rolling vs immutable tags⁠

It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.

⁠ Prometheus metrics

This chart can be integrated with Prometheus by setting metrics.enabled to true. This will expose the Harbor native Prometheus port in both the containers and services. The services will also have the necessary annotations to be automatically scraped by Prometheus.

⁠Prometheus requirements

It is necessary to have a working installation of Prometheus or Prometheus Operator for the integration to work. Install the Bitnami Prometheus helm chart⁠ or the Bitnami Kube Prometheus helm chart⁠ to easily have a working Prometheus in your cluster.

⁠Integration with Prometheus Operator

The chart can deploy ServiceMonitor objects for integration with Prometheus Operator installations. To do so, set the value metrics.serviceMonitor.enabled=true. Ensure that the Prometheus Operator CustomResourceDefinitions are installed in the cluster or it will fail with the following error:

no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"

Install the Bitnami Kube Prometheus helm chart⁠ for having the necessary CRDs and the Prometheus Operator.

⁠ Configure how to expose Harbor core

You can expose Harbor core using three methods:

• Gateway API HTTPRoute, exposureType should be set to httproute.
  • A Gateway controller must be installed in the Kubernetes cluster.
• An Ingress Controller, exposureType should be set to ingress.
  • An ingress controller must be installed in the Kubernetes cluster.
  • If the TLS is disabled, the port must be included in the command when pulling/pushing images. See issue #5291⁠ for the detail.
• An NGINX Proxy, exposureType should be set to proxy. There are three ways to do so depending on the NGINX Proxy service type:
  • ClusterIP: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster:
  • NodePort: Exposes the service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort service, from outside the cluster, by requesting NodeIP:NodePort.
  • LoadBalancer: Exposes the service externally using a cloud provider's load balancer.

⁠ Configure the external URL

The external URL for Harbor core service is used to:

1. populate the docker/helm commands showed on portal

Format: protocol://domain[:port]. Usually:

• If you expose Harbor core service using Gateway API HTTPRoute, the domain should be the value of httpRoute.hostnames[0].
• If you expose Harbor core service using Ingress, the domain should be the value of ingress.hostname.
• If you expose Harbor core using NGINX proxy with a ClusterIP service type, the domain should be the value of service.clusterIP.
• If you expose Harbor core using NGINX proxy with a NodePort service type, the domain should be the IP address of one Kubernetes node.
• If you expose Harbor core using NGINX proxy with a LoadBalancer service type, set the domain as your own domain name and add a CNAME record to map the domain name to the one you got from the cloud provider.

If Harbor is deployed behind the proxy, set it as the URL of proxy.

⁠ Update database schema

In order to update the database schema, the helm chart deploys a special Job that performs the migration. Enable this by setting the migration.enabled=true value.

This Job relies on helm hooks, so any upgrade operation will wait for this Job to succeed.

⁠ Securing traffic using TLS

It is possible to configure TLS communication in the core, jobservice, portal, registry and trivy components by setting internalTLS.enabled=true. The chart allows two configuration options:

• Provide your own secrets for Harbor components using the *.tls.existingSecret (under the core, jobservice, portal, registry and `trivy' sections) values.
• Have the chart auto-generate the certificates. This is done when not setting the *.tls.existingSecret values.

Additionally, it is possible to add a custom authority to each component trust store. This is done using the internalTLS.caBundleSecret value with the name of a secret containing the corresponding ca.crt file.

⁠ Backup and restore

To back up and restore Helm chart deployments on Kubernetes, you need to back up the persistent volumes from the source deployment and attach them to a new deployment using Velero⁠, a Kubernetes backup/restore tool. Find the instructions for using Velero in this guide⁠.

⁠ Sidecars and Init Containers

If you have a need for additional containers to run within the same pod as any of the Harbor components (e.g. an additional metrics or logging exporter), you can do so using the sidecars config parameter inside each component subsection. Simply define your container according to the Kubernetes container spec.

core:
  sidecars:
    - name: your-image-name
      image: your-image
      imagePullPolicy: Always
      ports:
        - name: portname
        containerPort: 1234

Similarly, you can add extra init containers using the initContainers parameter.

core:
  initContainers:
    - name: your-image-name
      image: your-image
      imagePullPolicy: Always
      ports:
        - name: portname
          containerPort: 1234

⁠ Adding extra environment variables

In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the extraEnvVars property inside each component subsection.

core:
  extraEnvVars:
    - name: LOG_LEVEL
      value: error

Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the extraEnvVarsCM or the extraEnvVarsSecret values inside each component subsection.

⁠ Configure data persistence

• Disable: The data does not survive the termination of a pod.
• Persistent Volume Claim(default): A default StorageClass is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the storageClass or set existingClaim if you have already existing persistent volumes to use.
• External Storage(only for images and charts): For images and charts, the supported external storage are: azure, gcs, s3 swift and oss.

⁠ Configure the secrets

• Secrets: Secrets are used for encryption and to secure communication between components. Fill core.secret, jobservice.secret and registry.secret to configure them statically using the Helm values. it expects the "key or password", not the secret name where secrets are stored.
• Certificates: Used for token encryption/decryption. Fill core.secretName to configure.

Secrets and certificates must be setup to avoid changes on every Helm upgrade (see: #107⁠).

If you want to manage full Secret objects by your own, you can use existingSecret & existingEnvVarsSecret parameters. This could be useful for some secure GitOps workflows, of course, you will have to ensure to define all expected keys for those secrets.

The core service have two Secret objects, the default one for data & communication which is very important as it's contains the data encryption key of your harbor instance ! and a second one which contains standard passwords, database access password, ... Keep in mind that the HARBOR_ADMIN_PASSWORD is only used to bootstrap your harbor instance, if you update it after the deployment, the password is updated in database, but the secret will remain the initial one.

⁠ Set pod affinity

This chart allows you to set your custom affinity using the XXX.affinity parameter(s). Find more information about pod affinity in the Kubernetes documentation⁠.

As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the bitnami/common⁠ chart. To do so, set the XXX.podAffinityPreset, XXX.podAntiAffinityPreset, or XXX.nodeAffinityPreset parameters.

⁠ Adjust permissions of persistent volume mountpoint

As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it.

By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination.

You can enable this initContainer by setting volumePermissions.enabled to true.

⁠ FIPS parameters

The FIPS parameters only have effect if you are using images from the Bitnami Secure Images catalog⁠.

For more information on this new support, please refer to the FIPS Compliance section⁠.

⁠ Parameters

The following subsections list global, common, and component-specific parameters.

⁠ Global parameters

⁠ Common Parameters

⁠ Harbor common parameters

⁠ Traffic Exposure Parameters

Note: the README for this chart is longer than the DockerHub length limit of 25000, so it has been trimmed. The full README can be found at https://techdocs.broadcom.com/us/en/vmware-tanzu/bitnami-secure-images/bitnami-secure-images/services/bsi-app-doc/apps-charts-harbor-index.html⁠