bitnamicharts/harbor Docker 镜像 - 轩辕镜像

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

console
helm install my-release oci://registry-1.docker.io/bitnamicharts/harbor

Why use Bitnami Secure Images?

Those are hardened, minimal CVE images built and maintained by Bitnami. Bitnami Secure Images are based on the cloud-optimized, security-hardened enterprise OS Photon Linux. Why choose BSI images?

• Hardened secure images of popular open source software with Near-Zero Vulnerabilities
• Vulnerability Triage & Prioritization with VEX Statements, KEV and EPSS Scores
• Compliance focus with FIPS, STIG, and air-gap options, including secure bill of materials (SBOM)
• Software supply chain provenance attestation through in-toto
• First class support for the internet’s favorite Helm charts

Each image comes with valuable security metadata. You can view the metadata in our public catalog here. Note: Some data is only available with commercial subscriptions to BSI.

!Alt text !Alt text

If you are looking for our previous generation of images based on Debian Linux, please see the Bitnami Legacy registry.

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:

• It is possible to pull all the required images from a private registry through 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.

Prerequisites

• Kubernetes 1.23+
• Helm 3.8.0+
• PV provisioner support in the underlying infrastructure
• ReadWriteMany volumes for deployment scaling

Installing the Chart

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

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

Note: You need to substitute the placeholders REGISTRY_NAME and REPOSITORY_NAME with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use REGISTRY_NAME=registry-1.docker.io and REPOSITORY_NAME=bitnamicharts.

Configuration and installation details

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:

text
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 the way how to expose Harbor core

You can expose Harbor core using two methods:

• 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. Refer to 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.
  • Load***: Exposes the service externally using a cloud provider's load ***.

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 expose Harbor core service via Ingress, the domain should be the value of ingress.core.hostname.
• if expose Harbor core via NGINX proxy using a ClusterIP service type, the domain should be the value of service.clusterIP.
• if expose Harbor core via NGINX proxy using a NodePort service type, the domain should be the IP address of one Kubernetes node.
• if expose Harbor core via NGINX proxy using a Load*** 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 via the sidecars config parameter inside each component subsection. Simply define your container according to the Kubernetes container spec.

yaml
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.

yaml
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.

yaml
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 external storages are supported: 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 then statically through 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 boostrap your harbor instance, if you update it after the deployment, the password is updated in database, but the secret will remain the initial one.

Setting Pod's affinity

This chart allows you to set your custom affinity using the XXX.affinity parameter(s). Find more information about Pod's 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.

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 [***]