## 1. Project Overview & Quickstart (goharbor/harbor) ## File: README.md # Harbor [](https://github.com/goharbor/harbor/actions/workflows/CI.yml) [](https://goreportcard.com/report/github.com/goharbor/harbor) [](https://codecov.io/gh/goharbor/harbor) [](https://bestpractices.coreinfrastructure.org/projects/2095) [](https://www.codacy.com/gh/goharbor/harbor/dashboard?utm_source=github.com&utm_medium=referral&utm_content=goharbor/harbor&utm_campaign=Badge_Grade) [](https://app.fossa.com/projects/git%2Bgithub.com%2Fgoharbor%2Fharbor?ref=badge_shield) [](https://artifacthub.io/packages/helm/harbor/harbor) [](https://scorecard.dev/viewer/?uri=github.com/goharbor/harbor) |Community Meeting| |------------------| |The Harbor Project holds bi-weekly community calls in two different timezones. To join the community calls or to watch previous meeting notes and recordings, please visit the [meeting schedule](https://github.com/goharbor/community/blob/master/MEETING_SCHEDULE.md).| **Note**: The `main` branch may be in an *unstable or even broken state* during development. Please use [releases](https://github.com/goharbor/harbor/releases) instead of the `main` branch in order to get a stable set of binaries. Harbor is an open source trusted cloud native registry project that stores, signs, and scans content. Harbor extends the open source Docker Distribution by adding the functionalities usually required by users such as security, identity and management. Having a registry closer to the build and run environment can improve the image transfer efficiency. Harbor supports replication of images between registries, and also offers advanced security features such as user management, access control and activity auditing. Harbor is hosted by the [Cloud Native Computing Foundation](https://cncf.io) (CNCF). If you are an organization that wants to help shape the evolution of cloud native technologies, consider joining the CNCF. For details about who is involved and how Harbor plays a role, read the CNCF [announcement](https://www.cncf.io/blog/2018/07/31/cncf-to-host-harbor-in-the-sandbox/). ## Features * **Cloud native registry**: With support for both container images and [Helm](https://helm.sh) charts, Harbor serves as registry for cloud native environments like container runtimes and orchestration platforms. * **Role based access control**: Users access different repositories through 'projects' and a user can have different permission for images or Helm charts under a project. * **Policy based replication**: Images and charts can be replicated (synchronized) between multiple registry instances based on policies with using filters (repository, tag and label). Harbor automatically retries a replication if it encounters any errors. This can be used to assist loadbalancing, achieve high availability, and facilitate multi-datacenter deployments in hybrid and multi-cloud scenarios. * **Vulnerability Scanning**: Harbor scans images regularly for vulnerabilities and has policy checks to prevent vulnerable images from being deployed. * **LDAP/AD support**: Harbor integrates with existing enterprise LDAP/AD for user authentication and management, and supports importing LDAP groups into Harbor that can then be given permissions to specific projects. * **OIDC support**: Harbor leverages OpenID Connect (OIDC) to verify the identity of users authenticated by an external authorization server or identity provider. Single sign-on can be enabled to log into the Harbor portal. * **Image deletion & garbage collection**: System administrators can run garbage collection jobs so that images (dangling manifests and unreferenced blobs) can be deleted and their space can be freed up periodically. * **Graphical user portal**: User can easily browse, search repositories and manage projects. * **Auditing**: All the operations to the repositories are tracked through logs. * **RESTful API**: RESTful APIs are provided to facilitate administrative operations, and are easy to use for integration with external systems. An embedded Swagger UI is available for exploring and testing the API. * **Easy deployment**: Harbor can be deployed via Docker compose as well Helm Chart, and a Harbor Operator was added recently as well. ## Architecture For learning the architecture design of Harbor, check the document [Architecture Overview of Harbor](https://github.com/goharbor/harbor/wiki/Architecture-Overview-of-Harbor). ## API * Harbor RESTful API: The APIs for most administrative operations of Harbor and can be used to perform integrations with Harbor programmatically. * Part 1: [New or changed APIs](https://editor.swagger.io/?url=https://raw.githubusercontent.com/goharbor/harbor/main/api/v2.0/swagger.yaml) ## Install & Run **System requirements:** **On a Linux host:** docker 20.10.10-ce+ and docker-compose 1.18.0+. Download binaries of **[Harbor release ](https://github.com/goharbor/harbor/releases)** and follow **[Installation & Configuration Guide](https://goharbor.io/docs/latest/install-config/)** to install Harbor. If you want to deploy Harbor on Kubernetes, please use the **[Harbor chart](https://github.com/goharbor/harbor-helm)**. Refer to the **[documentation](https://goharbor.io/docs/)** for more details on how to use Harbor. ### Verifying Release Signatures Starting with v2.15.0, Harbor release artifacts are cryptographically signed using Cosign to ensure authenticity and integrity. Download the installers and signature bundles from the Harbor releases page. #### Quick Verification ```bash # Install Cosign (v2.0+) brew install sigstore/tap/cosign # Verify signature cosign verify-blob \ --bundle harbor-offline-installer-v2.15.0.tgz.sigstore.json \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ --certificate-identity-regexp '^https://github.com/goharbor/harbor/.github/workflows/publish_release.yml@refs/tags/v.*$' \ harbor-offline-installer-v2.15.0.tgz ``` - *Expected output:* Verified OK - *Full verification guide:* [docs/signature-verification.md](docs/signature-verification.md) ## OCI Distribution Conformance Tests Check the OCI distribution conformance tests [report](https://storage.googleapis.com/harbor-conformance-test/report.html) of Harbor. ## Compatibility The [compatibility list](https://goharbor.io/docs/edge/install-config/harbor-compatibility-list/) document provides compatibility information for the Harbor components. * [Replication adapters](https://goharbor.io/docs/edge/install-config/harbor-compatibility-list/#replication-adapters) * [OIDC adapters](https://goharbor.io/docs/edge/install-config/harbor-compatibility-list/#oidc-adapters) * [Scanner adapters](https://goharbor.io/docs/edge/install-config/harbor-compatibility-list/#scanner-adapters) ## Community * **Twitter:** [@project_harbor](https://twitter.com/project_harbor) * **User Group:** Join Harbor user email group: [harbor-users@lists.cncf.io](https://lists.cncf.io/g/harbor-users) to get update of Harbor's news, features, releases, or to provide suggestion and feedback. * **Developer Group:** Join Harbor developer group: [harbor-dev@lists.cncf.io](https://lists.cncf.io/g/harbor-dev) for discussion on Harbor development and contribution. * **Slack:** Join Harbor's community for discussion and ask questions: [Cloud Native Computing Foundation](https://slack.cncf.io/), channel: [#harbor](https://cloud-native.slack.com/messages/harbor/) and [#harbor-dev](https://cloud-native.slack.com/messages/harbor-dev/) ## Demos * **[Live Demo](https://demo.goharbor.io)** - A demo environment with the latest Harbor stable build installed. For additional information please refer to [this page](https://goharbor.io/docs/latest/install-config/demo-server/). * **[Video Demos](https://github.com/goharbor/harbor/wiki/Video-demos-for-Harbor)** - Demos for Harbor features and continuously updated. ## Partners and Users For a list of users, please refer to [ADOPTERS.md](ADOPTERS.md). ## Security ### Security Audit A third party security audit was performed by Cure53 in October 2019. You can see the full report [here](https://goharbor.io/docs/2.0.0/security/Harbor_Security_Audit_Oct2019.pdf). ### Reporting security vulnerabilities If you've found a security related issue, a vulnerability, or a potential vulnerability in Harbor, do not file a public issue. Report it privately via [GitHub private vulnerability reporting](https://github.com/goharbor/harbor/security/advisories/new): open the [Security tab](https://github.com/goharbor/harbor/security) and click **Report a vulnerability**. The Harbor Security Team will acknowledge your report, and will follow up in the advisory thread once we've identified the issue positively or negatively. For further details please see our complete [security release process](SECURITY.md). ## License Harbor is available under the [Apache 2 license](LICENSE). This project uses open source components which have additional licensing terms. The official docker images and licensing terms for these open source components can be found at the following locations: * Photon OS 1.0: [docker image](https://hub.docker.com/_/photon/), [license](https://github.com/vmware/photon/blob/master/COPYING) ## Fossa Status [](https://app.fossa.com/projects/git%2Bgithub.com%2Fgoharbor%2Fharbor?ref=badge_large) --- ## File: api/v2.0/README.md # References This file lists all the files that are referring the swagger yaml file. - Makefile - `java -jar swagger-codegen-cli.jar generate -i api/harbor/swagger.yaml -l python -o harborclient` - README - `Harbor RESTful API` in `API` section - docs/configure_swagger.md - `https://raw.githubusercontent.com/goharbor/harbor/master/api/harbor/swagger.yaml` - make/photon/portal/Dockerfile - `COPY ./api/v2.0/swagger.yaml /build_dir/swagger.yaml` - tests/swaggerchecker.sh - `HARBOR_SWAGGER_FILE="https://raw.githubusercontent.com/$TRAVIS_REPO_SLUG/$TRAVIS_COMMIT/api/harbor/swagger.yaml"` - else `HARBOR_SWAGGER_FILE="https://raw.githubusercontent.com/$TRAVIS_PULL_REQUEST_SLUG/$TRAVIS_PULL_REQUEST_SHA/api/harbor/swagger.yaml"` **Notes:** Base path is the code repository root dir. --- ## File: contrib/grafana-dashboard/README.md # Grafana Dashboard This dashboard can be used to visualize metrics from the [Harbor Exporter](https://goharbor.io/docs/main/administration/metrics/). The dashboard was created with Grafana v8 and may not work with older versions of Grafana. ## Screenshot --- ## File: contrib/README.md The `contrib` directory contains documents, scripts, and other helpful things which are contributed by the community. --- ## File: docs/img/README.md **Note**: The `harbor_logo.png` is referenced by the Harbor helm charts which are already released, don't remove it --- ## File: docs/README.md # Harbor Documentation All Harbor documentation is presented on [goharbor.io/docs](https://goharbor.io/docs). To contribute to the documentation, please head over to the [website repository](https://github.com/goharbor/website). --- ## File: src/jobservice/README.md # Job Service Job service is designed to handle and process the asynchronous background jobs with an easy way. It is built on top of [gocraft/work](https://github.com/gocraft/work) job queue framework with supporting * Fast and efficient. * Reliable - don't lose jobs even if your process crashes. * If a job fails, it will be retried a specified number of times. * Schedule jobs to happen in the future. * Enqueue unique jobs so that only one job with a given name/arguments exists in the queue at once. * Periodically enqueue jobs on a cron-like schedule. and the following additional capabilities: * Rest API. * Execution context. * More job status: `error`,`success`,`stopped`,`cancelled` and `scheduled`. * More controllable actions: `stop` and `cancel`. * Enhanced periodical jobs. * Status web hook. ## Use cases With job service, you can: * Submit a `Generic` job which will be executed immediately if worker resource is available and can be only execute once. * Submit a `Scheduled` job which will be executed after a specified delay. * Submit a `Periodic` job which will be repeatedly executed with specified interval. * Submit job with `unique` flag to make sure no duplicated jobs are executing at the same time. * Stop a specified job. * Cancel a specified job. * Retry a specified job (This should be a failed job and match the retrying criteria). * Get stats of specified job (no list jobs function). * Get execution log of specified job (It depends on the logger implementation). * Check the health status of job service.(No authentication required, it can be used as health check endpoint) ## Architecture The overall architecture of the job service is shown in the below graph: Components: * API Server: A go lightweight restful API server to serve the related restful requests. * Configuration Manager: Responsible for handing the configurations used in job services. Two sources supported: yaml file and env variables. * Bootstrap: Take the responsibilities to initialize related context and start API server and worker pool. The main start point of job service. * Controller: The core of job service. Responsible for coordinating the whole flow of job service. * Job Launcher : Launch the jobs except `Periodic` ones. * Scheduler: Schedules the `Periodic` jobs. * Logger: A flexible logger framework. It will catch and write the job execution logs to the configured backends. * Stats Manager: Maintains the status and stats of jobs as well as status hooks. * Data Backend: Define storage methods to store the additional info. * Pool Driver: A interface layer to broke the functions of upstream job queue framework to upper layers. * Persistent driver: So far, only support `redis`. Currently, the worker (compute node) and controller (control plane) are packaged in one process. To achieve scalability and HA functionality, multiple nodes can be deployed under a LB layer. As described in above graph, the controller and work pool which are located in different nodes can also talk to each other via a virtual channel - the backend persistent driver. That means the job enqueued by a controller may be selected by other worker pool which is located in another node. ## Programming Model To let the job service recognize the job, the implementation of job should follow the programming model. ### Job Interface A valid job must implement the job interface. For the details of each method defined in the job interface, you can refer the comments attached with the method. ```go // Interface defines the related injection and run entry methods. type Interface interface { // Declare how many times the job can be retried if failed. // // Return: // uint: the failure count allowed. If it is set to 0, then default value 4 is used. MaxFails() uint // Max currency of the job. Unlike the WorkerPool concurrency, it controls the limit on the number jobs of that type // that can be active at one time by within a single redis instance. // // The default value is 0, which means "no limit on job concurrency". MaxCurrency() uint // Tell the worker worker if retry the failed job when the fails is // still less that the number declared by the method 'MaxFails'. // // Returns: // true for retry and false for none-retry ShouldRetry() bool // Indicate whether the parameters of job are valid. // // Return: // error if parameters are not valid. NOTES: If no parameters needed, directly return nil. Validate(params Parameters) error // Run the business logic here. // The related arguments will be injected by the workerpool. // // ctx Context : Job execution context. // params map[string]any : parameters with key-pair style for the job execution. // // Returns: // error if failed to run. NOTES: If job is stopped or cancelled, a specified error should be returned // Run(ctx Context, params Parameters) error } ``` Just pay attention, your main logic should be written in the `Run` method. ### Job Context A job context will be provided when executed the `Run` logic. With this context, you can * Get a logger handle if you want to output the execution log to the log backends. * Retrieve the system context reference. * Get job operation signal if your job supports `stop` and `cancel`. * Get the `checkin` func to check in message. * Get properties by key * Specified to harbor, db connection and all the configurations can be retrieved by context. ### Cancellable Job To make the job cancellable, some special logic should be coded in the `Run` logic. First, check the signal at certain execution points, ```go if cmd, ok := ctx.OPCommand(); ok {} ``` Then, check if it is a `cancel` signal, ```go if cmd == opm.CtlCommandCancel {} ``` finally, if it is, exit the logic and return the cancel error. ```go return errs.JobCancelledError() ``` ### Stoppable Job To make the job stoppable, some special logic should be coded in the `Run` logic. First, check the signal at certain execution points, ```go if cmd, ok := ctx.OPCommand(); ok {} ``` Then, check if it is a `stop` signal, ```go if cmd == opm.CtlCommandStop {} ``` finally, if it is, exit the logic and return the cancel error. ```go return errs.JobStoppedError() ``` ### Check In Message If you want to report more concrete status info, just call the `Checkin` function in the job context like the below code piece shown: ```go ctx.Checkin("30%") ``` ### Job Implementation Sample Here is a demo job: ``` /* Detailed source-code truncated for AI context efficiency. */ ``` ## Job Execution Job execution is used to track the jobs which are related to a specified job, like parent and children jobs. If one job has executions, the following two extra properties will be appended to the job stats. ```json { "job": { "executions": ["uuid-sub-job"], "multiple_executions": true } } ``` For the job execution/sub job, there will be an extra property `upstream_job_id` pointing to id of the upstream (/parent) job. ```json { "job": { "upstream_job_id": "parent-id" } } ``` Under that situation, the flag `multiple_executions` will be set to be `true`. The list `executions` will contain all the ids of the executions (/sub jobs). ### General job Any jobs can launch new jobs through the launch function in the job context. All those jobs will be tracked as sub jobs (executions) of the caller job. ```go func (j *Job) Run(ctx job.Context, params job.Parameters) error{ // ... subJob, err := ctx.LaunchJob(models.JobRequest{}) // ... return nil } ``` ### Periodic job The job launched with `Periodic` kind is actually a scheduled job template which will be not run directly. The real running job will be created by cloning the configurations from the job template and run. And then each _periodic job_ will have multiple job executions with independent id and each _job execution_ will link to the `Periodic` job by the `upstream_job_id`. ### Logger There are two loggers here. One is for job service itself and another one is for the running jobs. Each logger can configure multi logger backends. Each backend logger is identified by an unique name which will be used in the logger configurations to enable the corresponding loggers. Meanwhile, each backend logger MUST implement the `logger.Interface`. A logger can also support (optional): * _sweeper_: Sweep the outdated logs. A sweeper MUST implement `sweeper.Interface` * _getter_: Get the specified log data. A getter MUST implement `getter.Interface` All the backend loggers SHOULD onboard via the static logger registry. ```go // knownLoggers is a static logger registry. // All the implemented loggers (w/ sweeper) should be registered // with an unique name in this registry. Then they can be used to // log info. var knownLoggers = map[string]*Declaration{ // File logger LoggerNameFile: {FileFactory, FileSweeperFactory, FileGetterFactory, false}, // STD output(both stdout and stderr) logger LoggerNameStdOutput: {StdFactory, nil, nil, true}, } ``` So far, only the following two backends are supported: * **STD_OUTPUT**: Output the log to the std stream (stdout/stderr) * **DB**: Output the log to the database with the table name `job_log` * **FILE**: Output the log to the log files * sweeper supports * getter supports ### Configure loggers Logger configuration options: | Option | Description | |--------------|---------------------------| | loggers[x].name | The unique name of the logger backend | | loggers[x].level| The logger level of the logger backend| | loggers[x].settings | A hash map to pass extra settings of the logger backend. Depends on the implementation of the backend.| | loggers[x].sweeper.duration| The duration of the sweeper looping | | loggers[x].sweeper.settings| A hash map to pass extra settings of the sweeper. Depends on the implementation of sweeper. | An example: ```yaml #Loggers loggers: - name: "STD_OUTPUT" # logger backend name, only support "DB", "FILE" and "STD_OUTPUT" level: "DEBUG" # INFO/DEBUG/WARNING/ERROR/FATAL - name: "FILE" level: "DEBUG" settings: # Customized settings of logger base_dir: "/tmp/job_logs" sweeper: duration: 1 #days settings: # Customized settings of sweeper work_dir: "/tmp/job_logs" - name: "DB" level: "DEBUG" sweeper: duration: 1 #days ``` ## Configuration The following configuration options are supported: | Option | Description | ENV variable | |--------|-------------|--------------| | protocol | Protocol used to serve http | JOB_SERVICE_PROTOCOL | | https_config.cert| The tls cert if enabled https protocol|JOB_SERVICE_HTTPS_CERT| | https_config.key| The tls key if enabled https protocol|JOB_SERVICE_HTTPS_KEY| | port | API server listening port| JOB_SERVICE_PORT | | worker_pool.worker_pool | The worker concurrency number| JOB_SERVICE_POOL_WORKERS | | worker_pool.backend | The job data persistent backend driver. So far, only redis supported| JOB_SERVICE_POOL_BACKEND | | worker_pool.redis_pool.redis_url | The redis url if backend is redis| JOB_SERVICE_POOL_REDIS_URL | | worker_pool.redis_pool.namespace | The namespace used in redis| JOB_SERVICE_POOL_REDIS_NAMESPACE | | loggers | Loggers for job service itself. Refer to [Configure loggers](#configure-loggers)| | | job_loggers | Loggers for the running jobs. Refer to [Configure loggers](#configure-loggers) | | | core_server | The harbor core server endpoint which used to retrieve Harbor configures| CORE_URL | ### Sample ```yaml --- #Protocol used to serve protocol: "https" #Config certification if use 'https' protocol https_config: cert: "server.crt" key: "server.key" #Server listening port port: 9443 #Worker pool worker_pool: #Worker concurrency workers: 10 backend: "redis" #Additional config if use 'redis' backend redis_pool: #redis://[arbitrary_username:password@]ipaddress:port/database_index #or ipaddress:port[,weight,password,database_index] redis_url: "localhost:6379" namespace: "harbor_job_service" #Loggers for the running job job_loggers: - name: "STD_OUTPUT" # logger backend name, only support "DB", "FILE" and "STD_OUTPUT" level: "DEBUG" # INFO/DEBUG/WARNING/ERROR/FATAL - name: "FILE" level: "DEBUG" settings: # Customized settings of logger base_dir: "/tmp/job_logs" sweeper: duration: 1 #days settings: # Customized settings of sweeper work_dir: "/tmp/job_logs" - name: "DB" level: "DEBUG" sweeper: duration: 1 #days #Loggers for the job service loggers: - name: "STD_OUTPUT" # Same with above level: "DEBUG" ``` ## API ### Authorization As job service is always running in the backend environment, a simple secret auth way is choose now. To call the job service API, the `Authorization` header must be appended. ```go Authorization : Harbor-Secret ``` The expected secret is passed to job service by the ENV variable `CORE_SECRET`. ### Endpoints #### POST /api/v1/jobs > Submit jobs * Request body ```json { "job": { "name": "demo", "parameters": { "p1": "just a demo" }, "status_hook": "https://my-hook.com", "metadata": { "kind": "Generic", // or "Scheduled" or "Periodic" "schedule_delay": 90, // seconds, only required when kind is "Scheduled" "cron_spec": "* 5 * * * *", // only required when kind is "Periodic" "unique": false } } } ``` * Response * 202 Accepted ```json { "job": { "id": "uuid-job", "status": "pending", "name": "DEMO", "kind": "Generic", "unique": false, "ref_link": "/api/v1/jobs/uuid-job", "enqueue_time": "2018-10-10 12:00:00", "update_time": "2018-10-10 13:00:00", "multiple_executions": false // To indicate if the job has sub executions } } ``` * 401/500 Error ```json { "code": 500, "err": "short error message", "description": "detailed error message" } ``` #### GET /api/v1/jobs/{job_id} > Get job stats * Response * 200 OK ```json { "job": { "id": "uuid-job", "status": "pending", "name": "DEMO", "kind": "Periodic", "unique": false, "ref_link": "/api/v1/jobs/uuid-job", "enqueue_time": 1539164886, "update_time": 1539164886, "run_at": 1539164986, "cron_spec": "* 5 * * * * ", "check_in": "check in message", // if check in message "check_in_at": 1539164889, // if check in message "die_at": 0, "hook_status": "http://status-check.com", "executions": ["uuid-sub-job"], // the ids of sub executions of the job "multiple_executions": true } } ``` * 401/500 Error ```json { "code": 500, "err": "short error message", "description": "detailed error message" } ``` #### POST /api/v1/jobs/{job_id} > Stop/Cancel/Retry job * Request body ```json { "action": "stop" //or "cancel" or "retry" } ``` * Response * 204 No content * 401/404/500/501 Error ```json { "code": 500, "err": "short error message", "description": "detailed error message" } ``` #### GET /api/v1/jobs/{job_id}/log > Retrieve job log * Response * 200 OK Log text bytes * 401/400/404/500 Error ```json { "code": 500, "err": "short error message", "description": "detailed error message" } ``` #### GET /api/v1/stats > Check job service healthy status * Response * 200 OK ```json [{ "worker_pool_id": "pool1", "started_at": 1539164886, "heartbeat_at": 1539164986, "job_names": ["DEMO"], "concurrency": 10, "status": "healthy" }] ``` * 401/500 Error ```json { "code": 500, "err": "short error message", "description": "detailed error message" } ``` ## How to Run It's easy to run the job service. * First, compile and build the binary ```go // under jobservice folder go build -a -o jobservice ``` * Second, create configuration yaml file and [configure](#configuration) the job service. * Then, export the secret via ENV variable `CORE_SECRET`. * Finally, start the service with the following command, ```shell jobservice -c ``` Enjoy it! --- ## File: src/pkg/chart/testdata/harbor-schema2/README.md # Helm Chart for Harbor **Notes:** The master branch is in heavy development, please use the other stable versions instead. A highly available solution for Harbor based on chart can be found [here](docs/High%20Availability.md). And refer to the [guide](docs/Upgrade.md) to upgrade the existing deployment. This repository, including the issues, focuses on deploying Harbor chart via helm. For functionality issues or Harbor questions, please open issues on [goharbor/harbor](https://github.com/goharbor/harbor) ## Introduction This [Helm](https://github.com/kubernetes/helm) chart installs [Harbor](https://github.com/goharbor/harbor) in a Kubernetes cluster. Welcome to [contribute](CONTRIBUTING.md) to Helm Chart for Harbor. ## Prerequisites - Kubernetes cluster 1.20+ - Helm v3.2.0+ ## Installation ### Add Helm repository ```bash helm repo add harbor https://helm.goharbor.io ``` ### Configure the chart The following items can be set via `--set` flag during installation or configured by editing the `values.yaml` directly (need to download the chart first). #### Configure how to expose Harbor service - **Ingress**: The ingress controller must be installed in the Kubernetes cluster. **Notes:** if TLS is disabled, the port must be included in the command when pulling/pushing images. Refer to issue [#5291](https://github.com/goharbor/harbor/issues/5291) for details. - **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 2. populate the token service URL returned to docker client Format: `protocol://domain[:port]`. Usually: - if service exposed via `Ingress`, the `domain` should be the value of `expose.ingress.hosts.core` - if service exposed via `ClusterIP`, the `domain` should be the value of `expose.clusterIP.name` - if service exposed via `NodePort`, the `domain` should be the IP address of one Kubernetes node - if service exposed via `LoadBalancer`, 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. #### Configure how to persist data - **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 already have 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 other items listed in [configuration](#configuration) section ### Install the chart Install the Harbor helm chart with a release name `my-release`: ```bash helm install my-release harbor/harbor ``` ## Uninstallation To uninstall/delete the `my-release` deployment: ```bash helm uninstall my-release ``` ## Configuration The following table lists the configurable parameters of the Harbor chart and the default values. | Parameter | Description | Default | |-----------------------------------------------------------------------| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | **Expose** | | | | `expose.type` | How to expose the service: `ingress`, `clusterIP`, `nodePort` or `loadBalancer`, other values will be ignored and the creation of service will be skipped. | `ingress` | | `expose.tls.enabled` | Enable TLS or not. Delete the `ssl-redirect` annotations in `expose.ingress.annotations` when TLS is disabled and `expose.type` is `ingress`. Note: if the `expose.type` is `ingress` and TLS is disabled, the port must be included in the command when pulling/pushing images. Refer to https://github.com/goharbor/harbor/issues/5291 for details. | `true` | | `expose.tls.certSource` | The source of the TLS certificate. Set as `auto`, `secret` or `none` and fill the information in the corresponding section: 1) auto: generate the TLS certificate automatically 2) secret: read the TLS certificate from the specified secret. The TLS certificate can be generated manually or by cert manager 3) none: configure no TLS certificate for the ingress. If the default TLS certificate is configured in the ingress controller, choose this option | `auto` | | `expose.tls.auto.commonName` | The common name used to generate the certificate, it's necessary when the type isn't `ingress` | | | `expose.tls.secret.secretName` | The name of secret which contains keys named: `tls.crt` - the certificate; `tls.key` - the private key | | | `expose.ingress.hosts.core` | The host of Harbor core service in ingress rule | `core.harbor.domain` | | `expose.ingress.controller` | The ingress controller type. Currently supports `default`, `gce`, `alb`, `f5-bigip` and `ncp` | `default` | | `expose.ingress.kubeVersionOverride` | Allows the ability to override the kubernetes version used while templating the ingress | | | `expose.ingress.annotations` | The annotations used commonly for ingresses | | | `expose.ingress.labels` | The labels specific to ingress | {} | | `expose.clusterIP.name` | The name of ClusterIP service | `harbor` | | `expose.clusterIP.annotations` | The annotations attached to the ClusterIP service | {} | | `expose.clusterIP.ports.httpPort` | The service port Harbor listens on when serving HTTP | `80` | | `expose.clusterIP.ports.httpsPort` | The service port Harbor listens on when serving HTTPS | `443` | | `expose.clusterIP.annotations` | The annotations used commonly for clusterIP | | | `expose.clusterIP.labels` | The labels specific to clusterIP | {} | | `expose.nodePort.name` | The name of NodePort service | `harbor` | | `expose.nodePort.ports.http.port` | The service port Harbor listens on when serving HTTP | `80` | | `expose.nodePort.ports.http.nodePort` | The node port Harbor listens on when serving HTTP | `30002` | | `expose.nodePort.ports.https.port` | The service port Harbor listens on when serving HTTPS | `443` | | `expose.nodePort.ports.https.nodePort` | The node port Harbor listens on when serving HTTPS | `30003` | | `expose.nodePort.annotations` | The annotations used commonly for nodePort | | | `expose.nodePort.labels` | The labels specific to nodePort | {} | | `expose.loadBalancer.name` | The name of service | `harbor` | | `expose.loadBalancer.IP` | The IP of the loadBalancer. It only works when loadBalancer supports assigning IP | `""` | | `expose.loadBalancer.ports.httpPort` | The service port Harbor listens on when serving HTTP | `80` | | `expose.loadBalancer.ports.httpsPort` | The service port Harbor listens on when serving HTTPS | `30002` | | `expose.loadBalancer.annotations` | The annotations attached to the loadBalancer service | {} | | `expose.loadBalancer.labels` | The labels specific to loadBalancer | {} | | `expose.loadBalancer.sourceRanges` | List of IP address ranges to assign to loadBalancerSourceRanges | [] | | **Internal TLS** | | | | `internalTLS.enabled` | Enable TLS for the components (core, jobservice, portal, registry, trivy) | `false` | | `internalTLS.strong_ssl_ciphers` | Enable strong ssl ciphers for nginx and portal | `false` | `internalTLS.certSource` | Method to provide TLS for the components, options are `auto`, `manual`, `secret`. | `auto` | | `internalTLS.trustCa` | The content of trust CA, only available when `certSource` is `manual`. **Note**: all the internal certificates of the components must be issued by this CA | | | `internalTLS.core.secretName` | The secret name for core component, only available when `certSource` is `secret`. The secret must contain keys named: `ca.crt` - the CA certificate which is used to issue internal key and crt pair for components and all Harbor components must be issued by the same CA, `tls.crt` - the content of the TLS cert file, `tls.key` - the content of the TLS key file. | | | `internalTLS.core.crt` | Content of core's TLS cert file, only available when `certSource` is `manual` | | | `internalTLS.core.key` | Content of core's TLS key file, only available when `certSource` is `manual` | | | `internalTLS.jobservice.secretName` | The secret name for jobservice component, only available when `certSource` is `secret`. The secret must contain keys named: `ca.crt` - the CA certificate which is used to issue internal key and crt pair for components and all Harbor components must be issued by the same CA, `tls.crt` - the content of the TLS cert file, `tls.key` - the content of the TLS key file. | | | `internalTLS.jobservice.crt` | Content of jobservice's TLS cert file, only available when `certSource` is `manual` | | | `internalTLS.jobservice.key` | Content of jobservice's TLS key file, only available when `certSource` is `manual` | | | `internalTLS.registry.secretName` | The secret name for registry component, only available when `certSource` is `secret`. The secret must contain keys named: `ca.crt` - the CA certificate which is used to issue internal key and crt pair for components and all Harbor components must be issued by the same CA, `tls.crt` - the content of the TLS cert file, `tls.key` - the content of the TLS key file. | | | `internalTLS.registry.crt` | Content of registry's TLS cert file, only available when `certSource` is `manual` | | | `internalTLS.registry.key` | Content of registry's TLS key file, only available when `certSource` is `manual` | | | `internalTLS.portal.secretName` | The secret name for portal component, only available when `certSource` is `secret`. The secret must contain keys named: `ca.crt` - the CA certificate which is used to issue internal key and crt pair for components and all Harbor components must be issued by the same CA, `tls.crt` - the content of the TLS cert file, `tls.key` - the content of the TLS key file. | | | `internalTLS.portal.crt` | Content of portal's TLS cert file, only available when `certSource` is `manual` | | | `internalTLS.portal.key` | Content of portal's TLS key file, only available when `certSource` is `manual` | | | `internalTLS.trivy.secretName` | The secret name for trivy component, only available when `certSource` is `secret`. The secret must contain keys named: `ca.crt` - the CA certificate which is used to issue internal key and crt pair for components and all Harbor components must be issued by the same CA, `tls.crt` - the content of the TLS cert file, `tls.key` - the content of the TLS key file. | | | `internalTLS.trivy.crt` | Content of trivy's TLS cert file, only available when `certSource` is `manual` | | | `internalTLS.trivy.key` | Content of trivy's TLS key file, only available when `certSource` is `manual` | | | **IPFamily** | | | | `ipFamily.ipv4.enabled` | if cluster is ipv4 enabled, all ipv4 related configs will set correspondingly, but currently it only affects the nginx related components ｜ `true` | | `ipFamily.ipv6.enabled` | if cluster is ipv6 enabled, all ipv6 related configs will set correspondingly, but currently it only affects the nginx related components ｜ `true` | | **Persistence** | | | | `persistence.enabled` | Enable the data persistence or not | `true` | | `persistence.resourcePolicy` | Setting it to `keep` to avoid removing PVCs during a helm delete operation. Leaving it empty will delete PVCs after the chart deleted. Does not affect PVCs created for internal database and redis components. | `keep` | | `persistence.persistentVolumeClaim.registry.existingClaim` | Use the existing PVC which must be created manually before bound, and specify the `subPath` if the PVC is shared with other components | | | `persistence.persistentVolumeClaim.registry.storageClass` | Specify the `storageClass` used to provision the volume. Or the default StorageClass will be used (the default). Set it to `-` to disable dynamic provisioning | | | `persistence.persistentVolumeClaim.registry.subPath` | The sub path used in the volume | | | `persistence.persistentVolumeClaim.registry.accessMode` | The access mode of the volume | `ReadWriteOnce` | | `persistence.persistentVolumeClaim.registry.size` | The size of the volume | `5Gi` | | `persistence.persistentVolumeClaim.registry.annotations` | The annotations of the volume | | | `persistence.persistentVolumeClaim.jobservice.jobLog.existingClaim` | Use the existing PVC which must be created manually before bound, and specify the `subPath` if the PVC is shared with other components. | | | `persistence.persistentVolumeClaim.jobservice.jobLog.storageClass` | Specify the `storageClass` used to provision the volume. Or the default StorageClass will be used (the default). Set it to `-` to disable dynamic provisioning | | | `persistence.persistentVolumeClaim.jobservice.jobLog.subPath` | The sub path used in the volume | | | `persistence.persistentVolumeClaim.jobservice.jobLog.accessMode` | The access mode of the volume | `ReadWriteOnce` | | `persistence.persistentVolumeClaim.jobservice.jobLog.size` | The size of the volume | `1Gi` | | `persistence.persistentVolumeClaim.jobservice.jobLog.annotations` | The annotations of the volume | | | `persistence.persistentVolumeClaim.database.existingClaim` | Use the existing PVC which must be created manually before bound, and specify the `subPath` if the PVC is shared with other components. If external database is used, the setting will be ignored | | | `persistence.persistentVolumeClaim.database.storageClass` | Specify the `storageClass` used to provision the volume. Or the default StorageClass will be used (the default). Set it to `-` to disable dynamic provisioning. If external database is used, the setting will be ignored | | | `persistence.persistentVolumeClaim.database.subPath` | The sub path used in the volume. If external database is used, the setting will be ignored | | | `persistence.persistentVolumeClaim.database.accessMode` | The access mode of the volume. If external database is used, the setting will be ignored | `ReadWriteOnce` | | `persistence.persistentVolumeClaim.database.size` | The size of the volume. If external database is used, the setting will be ignored | `1Gi` | | `persistence.persistentVolumeClaim.database.annotations` | The annotations of the volume | | | `persistence.persistentVolumeClaim.redis.existingClaim` | Use the existing PVC which must be created manually before bound, and specify the `subPath` if the PVC is shared with other components. If external Redis is used, the setting will be ignored | | | `persistence.persistentVolumeClaim.redis.storageClass` | Specify the `storageClass` used to provision the volume. Or the default StorageClass will be used (the default). Set it to `-` to disable dynamic provisioning. If external Redis is used, the setting will be ignored | | | `persistence.persistentVolumeClaim.redis.subPath` | The sub path used in the volume. If external Redis is used, the setting will be ignored | | | `persistence.persistentVolumeClaim.redis.accessMode` | The access mode of the volume. If external Redis is used, the setting will be ignored | `ReadWriteOnce` | | `persistence.persistentVolumeClaim.redis.size` | The size of the volume. If external Redis is used, the setting will be ignored | `1Gi` | | `persistence.persistentVolumeClaim.redis.annotations` | The annotations of the volume | | | `persistence.persistentVolumeClaim.trivy.existingClaim` | Use the existing PVC which must be created manually before bound, and specify the `subPath` if the PVC is shared with other components | | | `persistence.persistentVolumeClaim.trivy.storageClass` | Specify the `storageClass` used to provision the volume. Or the default StorageClass will be used (the default). Set it to `-` to disable dynamic provisioning | | | `persistence.persistentVolumeClaim.trivy.subPath` | The sub path used in the volume | | | `persistence.persistentVolumeClaim.trivy.accessMode` | The access mode of the volume | `ReadWriteOnce` | | `persistence.persistentVolumeClaim.trivy.size` | The size of the volume | `1Gi` | | `persistence.persistentVolumeClaim.trivy.annotations` | The annotations of the volume | | | `persistence.imageChartStorage.disableredirect` | The configuration for managing redirects from content backends. For backends which not supported it (such as using minio for `s3` storage type), please set it to `true` to disable redirects. Refer to the [guide](https://github.com/docker/distribution/blob/master/docs/configuration.md#redirect) for more details | `false` | | `persistence.imageChartStorage.caBundleSecretName` | Specify the `caBundleSecretName` if the storage service uses a self-signed certificate. The secret must contain keys named `ca.crt` which will be injected into the trust store of registry's and containers. | | | `persistence.imageChartStorage.type` | The type of storage for images and charts: `filesystem`, `azure`, `gcs`, `s3`, `swift` or `oss`. The type must be `filesystem` if you want to use persistent volumes for registry. Refer to the [guide](https://github.com/docker/distribution/blob/master/docs/configuration.md#storage) for more details | `filesystem` | | `persistence.imageChartStorage.gcs.existingSecret` | An existing secret containing the gcs service account json key. The key must be gcs-key.json. | `""` | | `persistence.imageChartStorage.gcs.useWorkloadIdentity` | A boolean to allow the use of workloadidentity in a GKE cluster. To use it, create a kubernetes service account and set the name in the key `serviceAccountName` of each component, then allow automounting the service account. | `false` | | **General** | | | | `externalURL` | The external URL for Harbor core service | `https://core.harbor.domain` | | `caBundleSecretName` | The custom CA bundle secret name, the secret must contain key named "ca.crt" which will be injected into the trust store for core, jobservice, registry, trivy components. | | | `uaaSecretName` | If using external UAA auth which has a self signed cert, you can provide a pre-created secret containing it under the key `ca.crt`. | | | `imagePullPolicy` | The image pull policy | | | `imagePullSecrets` | The imagePullSecrets names for all deployments | | | `updateStrategy.type` | The update strategy for deployments with persistent volumes(jobservice, registry): `RollingUpdate` or `Recreate`. Set it as `Recreate` when `RWM` for volumes isn't supported | `RollingUpdate` | | `logLevel` | The log level: `debug`, `info`, `warning`, `error` or `fatal` | `info` | | `harborAdminPassword` | The initial password of Harbor admin. Change it from portal after launching Harbor | `Harbor12345` | | `existingSecretAdminPassword` | The name of secret where admin password can be found. | | | `existingSecretAdminPasswordKey` | The name of the key in the secret where to find harbor admin password Harbor | `HARBOR_ADMIN_PASSWORD` | | `caSecretName` | The name of the secret which contains key named `ca.crt`. Setting this enables the download link on portal to download the CA certificate when the certificate isn't generated automatically | | | `secretKey` | The key used for encryption. Must be a string of 16 chars | `not-a-secure-key` | | `existingSecretSecretKey` | An existing secret containing the encoding secretKey | `""` | | `proxy.httpProxy` | The URL of the HTTP proxy server | | | `proxy.httpsProxy` | The URL of the HTTPS proxy server | | | `proxy.noProxy` | The URLs that the proxy settings not apply to | 127.0.0.1,localhost,.local,.internal | | `proxy.components` | The component list that the proxy settings apply to | core, jobservice, trivy | | `enableMigrateHelmHook` | Run the migration job via helm hook, if it is true, the database migration will be separated from harbor-core, run with a preupgrade job migration-job | `false` | | **Nginx** (if service exposed via `ingress`, Nginx will not be used) | | | | `nginx.image.repository` | Image repository | `goharbor/nginx-photon` | | `nginx.image.tag` | Image tag | `dev` | | `nginx.replicas` | The replica count | `1` | | `nginx.revisionHistoryLimit` | The revision history limit | `10` | | `nginx.resources` | The [resources] to allocate for container | undefined | | `nginx.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `nginx.nodeSelector` | Node labels for pod assignment | `{}` | | `nginx.tolerations` | Tolerations for pod assignment | `[]` | | `nginx.affinity` | Node/Pod affinities | `{}` | | `nginx.topologySpreadConstraints` | Constraints that define how Pods are spread across failure-domains like regions or availability zones | `[]` | | `nginx.podAnnotations` | Annotations to add to the nginx pod | `{}` | | `nginx.priorityClassName` | The priority class to run the pod as | | | **Portal** | | | | `portal.image.repository` | Repository for portal image | `goharbor/harbor-portal` | | `portal.image.tag` | Tag for portal image | `dev` | | `portal.replicas` | The replica count | `1` | | `portal.revisionHistoryLimit` | The revision history limit | `10` | | `portal.resources` | The [resources] to allocate for container | undefined | | `portal.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `portal.nodeSelector` | Node labels for pod assignment | `{}` | | `portal.tolerations` | Tolerations for pod assignment | `[]` | | `portal.affinity` | Node/Pod affinities | `{}` | | `portal.topologySpreadConstraints` | Constraints that define how Pods are spread across failure-domains like regions or availability zones | `[]` | | `portal.podAnnotations` | Annotations to add to the portal pod | `{}` | | `portal.serviceAnnotations` | Annotations to add to the portal service | `{}` | | `portal.priorityClassName` | The priority class to run the pod as | | | `portal.initContainers` | Init containers to be run before the controller's container starts. | `[]` | | **Core** | | | | `core.image.repository` | Repository for Harbor core image | `goharbor/harbor-core` | | `core.image.tag` | Tag for Harbor core image | `dev` | | `core.replicas` | The replica count | `1` | | `core.revisionHistoryLimit` | The revision history limit | `10` | | `core.startupProbe.initialDelaySeconds` | The initial delay in seconds for the startup probe | `10` | | `core.resources` | The [resources] to allocate for container | undefined | | `core.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `core.nodeSelector` | Node labels for pod assignment | `{}` | | `core.tolerations` | Tolerations for pod assignment | `[]` | | `core.affinity` | Node/Pod affinities | `{}` | | `core.topologySpreadConstraints` | Constraints that define how Pods are spread across failure-domains like regions or availability zones | `[]` | | `core.podAnnotations` | Annotations to add to the core pod | `{}` | | `core.serviceAnnotations` | Annotations to add to the core service | `{}` | | `core.configureUserSettings` | A JSON string to set in the environment variable `CONFIG_OVERWRITE_JSON` to configure user settings. See the [official docs](https://goharbor.io/docs/latest/install-config/configure-user-settings-cli/#configure-users-settings-using-an-environment-variable). | | | `core.quotaUpdateProvider` | The provider for updating project quota(usage), there are 2 options, redis or db. By default it is implemented by db but you can configure it to redis which can improve the performance of high concurrent pushing to the same project, and reduce the database connections spike and occupies. Using redis will bring up some delay for quota usage updation for display, so only suggest switch provider to redis if you were ran into the db connections spike around the scenario of high concurrent pushing to same project, no improvment for other scenes. | `db` | | `core.secret` | Secret is used when core server communicates with other components. If a secret key is not specified, Helm will generate one. Must be a string of 16 chars. | | | `core.secretName` | Fill the name of a kubernetes secret if you want to use your own TLS certificate and private key for token encryption/decryption. The secret must contain keys named: `tls.crt` - the certificate and `tls.key` - the private key. The default key pair will be used if it isn't set | | | `core.tokenKey` | PEM-formatted RSA private key used to sign service tokens. Only used if `core.secretName` is unset. If set, `core.tokenCert` MUST also be set. | | | `core.tokenCert` | PEM-formatted certificate signed by `core.tokenKey` used to validate service tokens. Only used if `core.secretName` is unset. If set, `core.tokenKey` MUST also be set. | | | `core.xsrfKey` | The XSRF key. Will be generated automatically if it isn't specified | | | `core.priorityClassName` | The priority class to run the pod as | | | `core.artifactPullAsyncFlushDuration` | The time duration for async update artifact pull_time and repository pull_count | | | `core.gdpr.deleteUser` | Enable GDPR compliant user delete | `false` | | `core.gdpr.auditLogsCompliant` | Enable GDPR compliant for audit logs by changing username to its CRC32 value if that user was deleted from the system | `false` | | `core.initContainers` | Init containers to be run before the controller's container starts. | `[]` | | **Jobservice** | | | | `jobservice.image.repository` | Repository for jobservice image | `goharbor/harbor-jobservice` | | `jobservice.image.tag` | Tag for jobservice image | `dev` | | `jobservice.replicas` | The replica count | `1` | | `jobservice.revisionHistoryLimit` | The revision history limit | `10` | | `jobservice.maxJobWorkers` | The max job workers | `10` | | `jobservice.jobLoggers` | The loggers for jobs: `file`, `database` or `stdout` | `[file]` | | `jobservice.loggerSweeperDuration` | The jobLogger sweeper duration in days (ignored if `jobLoggers` is set to `stdout`) | `14` | | `jobservice.notification.webhook_job_max_retry` | The maximum retry of webhook sending notifications | `3` | | `jobservice.notification.webhook_job_http_client_timeout` | The http client timeout value of webhook sending notifications | `3` | | `jobservice.reaper.max_update_hours` | the max time to wait for a task to finish, if unfinished after max_update_hours, the task will be mark as error, but the task will continue to run, default value is 24 | `24` | | `jobservice.reaper.max_dangling_hours` | the max time for execution in running state without new task created | `168` | | `jobservice.resources` | The [resources] to allocate for container | undefined | | `jobservice.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `jobservice.nodeSelector` | Node labels for pod assignment | `{}` | | `jobservice.tolerations` | Tolerations for pod assignment | `[]` | | `jobservice.affinity` | Node/Pod affinities | `{}` | | `jobservice.topologySpreadConstraints` | Constraints that define how Pods are spread across failure-domains like regions or availability zones | `[]` | | `jobservice.podAnnotations` | Annotations to add to the jobservice pod | `{}` | | `jobservice.priorityClassName` | The priority class to run the pod as | | | `jobservice.secret` | Secret is used when job service communicates with other components. If a secret key is not specified, Helm will generate one. Must be a string of 16 chars. | | | `jobservice.initContainers` | Init containers to be run before the controller's container starts. | `[]` | | **Registry** | | | | `registry.registry.image.repository` | Repository for registry image | `goharbor/registry-photon` | | `registry.registry.image.tag` | Tag for registry image | `dev` | | `registry.registry.resources` | The [resources] to allocate for container | undefined | | `registry.controller.image.repository` | Repository for registry controller image | `goharbor/harbor-registryctl` | | `registry.controller.image.tag` | Tag for registry controller image | `dev` | | `registry.controller.resources` | The [resources] to allocate for container | undefined | | `registry.replicas` | The replica count | `1` | | `registry.revisionHistoryLimit` | The revision history limit | `10` | | `registry.nodeSelector` | Node labels for pod assignment | `{}` | | `registry.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `registry.tolerations` | Tolerations for pod assignment | `[]` | | `registry.affinity` | Node/Pod affinities | `{}` | | `registry.topologySpreadConstraints` | Constraints that define how Pods are spread across failure-domains like regions or availability zones | `[]` | | `registry.middleware` | Middleware is used to add support for a CDN between backend storage and `docker pull` recipient. See [official docs](https://github.com/docker/distribution/blob/master/docs/configuration.md#middleware). | | | `registry.podAnnotations` | Annotations to add to the registry pod | `{}` | | `registry.priorityClassName` | The priority class to run the pod as | | | `registry.secret` | Secret is used to secure the upload state from client and registry storage backend. See [official docs](https://github.com/docker/distribution/blob/master/docs/configuration.md#http). If a secret key is not specified, Helm will generate one. Must be a string of 16 chars. | | | `registry.credentials.username` | The username that harbor core uses internally to access the registry instance. Together with the `registry.credentials.password`, a htpasswd is created. This is an alternative to providing `registry.credentials.htpasswdString`. For more details see [official docs](https://github.com/docker/distribution/blob/master/docs/configuration.md#htpasswd). | `harbor_registry_user` | | `registry.credentials.password` | The password that harbor core uses internally to access the registry instance. Together with the `registry.credentials.username`, a htpasswd is created. This is an alternative to providing `registry.credentials.htpasswdString`. For more details see [official docs](https://github.com/docker/distribution/blob/master/docs/configuration.md#htpasswd). It is suggested you update this value before installation. | `harbor_registry_password` | | `registry.credentials.existingSecret` | An existing secret containing the password for accessing the registry instance, which is hosted by htpasswd auth mode. More details see [official docs](https://github.com/docker/distribution/blob/master/docs/configuration.md#htpasswd). The key must be `REGISTRY_PASSWD` | `""` | | `registry.credentials.htpasswdString` | Login and password in htpasswd string format. Excludes `registry.credentials.username` and `registry.credentials.password`. May come in handy when integrating with tools like argocd or flux. This allows the same line to be generated each time the template is rendered, instead of the `htpasswd` function from helm, which generates different lines each time because of the salt. | undefined | | `registry.relativeurls` | If true, the registry returns relative URLs in Location headers. The client is responsible for resolving the correct URL. Needed if harbor is behind a reverse proxy | `false` | | `registry.upload_purging.enabled` | If true, enable purge _upload directories | `true` | | `registry.upload_purging.age` | Remove files in _upload directories which exist for a period of time, default is one week. | `168h` | | `registry.upload_purging.interval` | The interval of the purge operations | `24h` | | `registry.upload_purging.dryrun` | If true, enable dryrun for purging _upload, default false | `false` | | `registry.initContainers` | Init containers to be run before the controller's container starts. | `[]` | | **[Trivy][trivy]** | | | | `trivy.enabled` | The flag to enable Trivy scanner | `true` | | `trivy.image.repository` | Repository for Trivy adapter image | `goharbor/trivy-adapter-photon` | | `trivy.image.tag` | Tag for Trivy adapter image | `dev` | | `trivy.resources` | The [resources] to allocate for Trivy adapter container | | | `trivy.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `trivy.replicas` | The number of Pod replicas | `1` | | `trivy.debugMode` | The flag to enable Trivy debug mode | `false` | | `trivy.vulnType` | Comma-separated list of vulnerability types. Possible values `os` and `library`. | `os,library` | | `trivy.severity` | Comma-separated list of severities to be checked | `UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL` | | `trivy.ignoreUnfixed` | The flag to display only fixed vulnerabilities | `false` | | `trivy.insecure` | The flag to skip verifying registry certificate | `false` | | `trivy.skipUpdate` | The flag to disable [Trivy DB][trivy-db] downloads from GitHub | `false` | | `trivy.skipJavaDBUpdate` | If the flag is enabled you have to manually download the `trivy-java.db` file [Trivy Java DB][trivy-java-db] and mount it in the `/home/scanner/.cache/trivy/java-db/trivy-java.db` path | `false` | | `trivy.offlineScan` | The flag prevents Trivy from sending API requests to identify dependencies. | `false` | | `trivy.securityCheck` | Comma-separated list of what security issues to detect. Possible values are `vuln`, `config` and `secret`. | `vuln` | | `trivy.timeout` | The duration to wait for scan completion | `5m0s` | | `trivy.gitHubToken` | The GitHub access token to download [Trivy DB][trivy-db] (see [GitHub rate limiting][trivy-rate-limiting]) | | | `trivy.priorityClassName` | The priority class to run the pod as | | | `trivy.topologySpreadConstraints` | The priority class to run the pod as | | | `trivy.initContainers` | Init containers to be run before the controller's container starts. | `[]` | | **Database** | | | | `database.type` | If external database is used, set it to `external` | `internal` | | `database.internal.image.repository` | Repository for database image | `goharbor/harbor-db` | | `database.internal.image.tag` | Tag for database image | `dev` | | `database.internal.password` | The password for database | `changeit` | | `database.internal.shmSizeLimit` | The limit for the size of shared memory for internal PostgreSQL, conventionally it's around 50% of the memory limit of the container | `512Mi` | | `database.internal.resources` | The [resources] to allocate for container | undefined | | `database.internal.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `database.internal.initContainer.migrator.resources` | The [resources] to allocate for the database migrator initContainer | undefined | | `database.internal.initContainer.permissions.resources` | The [resources] to allocate for the database permissions initContainer | undefined | | `database.internal.nodeSelector` | Node labels for pod assignment | `{}` | | `database.internal.tolerations` | Tolerations for pod assignment | `[]` | | `database.internal.affinity` | Node/Pod affinities | `{}` | | `database.internal.priorityClassName` | The priority class to run the pod as | | | `database.internal.livenessProbe.timeoutSeconds` | The timeout used in liveness probe; 1 to 5 seconds | 1 | | `database.internal.readinessProbe.timeoutSeconds` | The timeout used in readiness probe; 1 to 5 seconds | 1 | | `database.internal.extrInitContainers` | Extra init containers to be run before the database's container starts. | `[]` | | `database.external.host` | The hostname of external database | `192.168.0.1` | | `database.external.port` | The port of external database | `5432` | | `database.external.username` | The username of external database | `user` | | `database.external.password` | The password of external database | `password` | | `database.external.coreDatabase` | The database used by core service | `registry` | | `database.external.existingSecret` | An existing password containing the database password. the key must be `password`. | `""` | | `database.external.sslmode` | Connection method of external database (require, verify-full, verify-ca, disable) | `disable` | | `database.maxIdleConns` | The maximum number of connections in the idle connection pool. If it <=0, no idle connections are retained. | `50` | | `database.maxOpenConns` | The maximum number of open connections to the database. If it <= 0, then there is no limit on the number of open connections. | `100` | | `database.podAnnotations` | Annotations to add to the database pod | `{}` | | **Redis** | | | | `redis.type` | If external redis is used, set it to `external` | `internal` | | `redis.internal.image.repository` | Repository for redis image | `goharbor/redis-photon` | | `redis.internal.image.tag` | Tag for redis image | `dev` | | `redis.internal.resources` | The [resources] to allocate for container | undefined | | `redis.internal.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `redis.internal.nodeSelector` | Node labels for pod assignment | `{}` | | `redis.internal.tolerations` | Tolerations for pod assignment | `[]` | | `redis.internal.affinity` | Node/Pod affinities | `{}` | | `redis.internal.priorityClassName` | The priority class to run the pod as | | | `redis.internal.jobserviceDatabaseIndex` | The database index for jobservice | `1` | | `redis.internal.registryDatabaseIndex` | The database index for registry | `2` | | `redis.internal.trivyAdapterIndex` | The database index for trivy adapter | `5` | | `redis.internal.harborDatabaseIndex` | The database index for harbor miscellaneous business logic | `0` | | `redis.internal.cacheLayerDatabaseIndex` | The database index for harbor cache layer | `0` | | `redis.internal.initContainers` | Init containers to be run before the redis's container starts. | `[]` | | `redis.external.addr` | The addr of external Redis: :. When using sentinel, it should be :,:,: | `192.168.0.2:6379` | | `redis.external.sentinelMasterSet` | The name of the set of Redis instances to monitor | | | `redis.external.coreDatabaseIndex` | The database index for core | `0` | | `redis.external.jobserviceDatabaseIndex` | The database index for jobservice | `1` | | `redis.external.registryDatabaseIndex` | The database index for registry | `2` | | `redis.external.trivyAdapterIndex` | The database index for trivy adapter | `5` | | `redis.external.harborDatabaseIndex` | The database index for harbor miscellaneous business logic | `0` | | `redis.external.cacheLayerDatabaseIndex` | The database index for harbor cache layer | `0` | | `redis.external.username` | The username of external Redis | | | `redis.external.password` | The password of external Redis | | | `redis.external.existingSecret` | Use an existing secret to connect to redis. The key must be `REDIS_PASSWORD`. | `""` | | `redis.podAnnotations` | Annotations to add to the redis pod | `{}` | | **Exporter** | | | | `exporter.replicas` | The replica count | `1` | | `exporter.revisionHistoryLimit` | The revision history limit | `10` | | `exporter.podAnnotations` | Annotations to add to the exporter pod | `{}` | | `exporter.image.repository` | Repository for redis image | `goharbor/harbor-exporter` | | `exporter.image.tag` | Tag for exporter image | `dev` | | `exporter.nodeSelector` | Node labels for pod assignment | `{}` | | `exporter.tolerations` | Tolerations for pod assignment | `[]` | | `exporter.affinity` | Node/Pod affinities | `{}` | | `exporter.topologySpreadConstraints` | Constraints that define how Pods are spread across failure-domains like regions or availability zones | `[]` | | `exporter.automountServiceAccountToken` | Mount serviceAccountToken? | `false` | | `exporter.cacheDuration` | the cache duration for information that exporter collected from Harbor | `30` | | `exporter.cacheCleanInterval` | cache clean interval for information that exporter collected from Harbor | `14400` | | `exporter.priorityClassName` | The priority class to run the pod as | | | **Metrics** | | | | `metrics.enabled` | if enable harbor metrics | `false` | | `metrics.core.path` | the url path for core metrics | `/metrics` | | `metrics.core.port` | the port for core metrics | `8001` | | `metrics.registry.path` | the url path for registry metrics | `/metrics` | | `metrics.registry.port` | the port for registry metrics | `8001` | | `metrics.exporter.path` | the url path for exporter metrics | `/metrics` | | `metrics.exporter.port` | the port for exporter metrics | `8001` | | `metrics.serviceMonitor.enabled` | create prometheus serviceMonitor. Requires prometheus CRD's | `false` | | `metrics.serviceMonitor.additionalLabels` | additional labels to upsert to the manifest | `""` | | `metrics.serviceMonitor.interval` | scrape period for harbor metrics | `""` | | `metrics.serviceMonitor.metricRelabelings` | metrics relabel to add/mod/del before ingestion | `[]` | | `metrics.serviceMonitor.relabelings` | relabels to add/mod/del to sample before scrape | `[]` | | **Trace** | | | | `trace.enabled` | Enable tracing or not | `false` | | `trace.provider` | The tracing provider: `jaeger` or `otel`. `jaeger` should be 1.26+ | `jaeger` | | `trace.sample_rate` | Set `sample_rate` to 1 if you want sampling 100% of trace data; set 0.5 if you want sampling 50% of trace data, and so forth | `1` | | `trace.namespace` | Namespace used to differentiate different harbor services | | | `trace.attributes` | `attributes` is a key value dict contains user defined attributes used to initialize trace provider | | | `trace.jaeger.endpoint` | The endpoint of jaeger | `http://hostname:14268/api/traces` | | `trace.jaeger.username` | The username of jaeger | | | `trace.jaeger.password` | The password of jaeger | | | `trace.jaeger.agent_host` | The agent host of jaeger | | | `trace.jaeger.agent_port` | The agent port of jaeger | `6831` | | `trace.otel.endpoint` | The endpoint of otel | `hostname:4318` | | `trace.otel.url_path` | The URL path of otel | `/v1/traces` | | `trace.otel.compression` | Whether enable compression or not for otel | `false` | | `trace.otel.insecure` | Whether establish insecure connection or not for otel | `true` | | `trace.otel.timeout` | The timeout in seconds of otel | `10` | | **Cache** | | | | `cache.enabled` | Enable cache layer or not | `false` | | `cache.expireHours` | The expire hours of cache layer | `24` | [resources]: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ [trivy]: https://github.com/aquasecurity/trivy [trivy-db]: https://github.com/aquasecurity/trivy-db [trivy-java-db]: https://github.com/aquasecurity/trivy-java-db [trivy-rate-limiting]: https://github.com/aquasecurity/trivy#github-rate-limiting ## 2. Official Technical Reference & Guides (goharbor/website) ## File: README.md # The Harbor website [](https://app.fossa.com/projects/git%2Bgithub.com%2Fgoharbor%2Fwebsite?ref=badge_shield) This repo houses the assets used to build the Harbor website, available at https://goharbor.io. ## Tools The website is built and developed using the [Hugo](https://gohugo.io/) static site generator. Instructions for installing Hugo can be found [here](https://gohugo.io/getting-started/installing/). Use the version of Hugo specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](./netlify.toml) configuration file, and make sure to install the "extended" version of Hugo with support for [Hugo Pipes](https://gohugo.io/hugo-pipes/introduction/). [backport](https://github.com/sqren/backport) is used to backport PRs into different release branches. ## Website content The content for the [Harbor blog](https://goharbor.io/blog) is in [`content/blog`](./content/blog), while the content for the Harbor documentation is in the [`docs`](./docs) folder. The latest (edge) version of the documentation lives in the [`docs`](./docs) folder on the `main` branch, and is always viewable on https://goharbor.io/docs/edge. Documentation for specific released versions lives in its own release branch, for example `release-2.1.0`. ### Creating a PR In general, all PRs should be made against the `main` branch to update the edge version of the docs. If you are making a change that also affects released versions, indicate which release branches to update in your PR so a website maintainer can backport your changes. If you are making a change that is specific to a single released version of documentation, make a PR against that branch (`release-X`). For example, if you are fixing something specific to v2.1.0 you should make a PR against the release-2.1.0 branch only. If you are fixing something that impacts v2.1.0 docs and all future versions, you should make the PR against the `main` branch so the change can also be backported to the v2.1.0 docs. A preview of your changes is viewable through the Netlify preview linked in the PR tests. Use this to verify that your changes look good before asking the maintainers for a review. When updating the edge version make sure you add `/docs/edge/` to the preview URL to see your changes. ### Creating release docs When creating docs for a new release, please create a branch with the format `release-X.Y.Z`. When you want to make these docs available through the dropdown menu, put the following into the `config.toml` file, above all other versions (versions are linked based on order in the config file): ``` [[params.versions]] harborversion = "X.Y.Z" helmversion = "1.3" branchname = "release-X.Y.Z" ``` As last step, update the [_index.md](https://github.com/goharbor/website/blob/master/docs/_index.md) file with the new version number and correct links. After a release, update the [backport](https://github.com/sqren/backport) tool configuration file, `.backportrc.json`, with the new release branch name. ### CSS The CSS for the site is built from [Sass](https://sass-lang.com) inputs in the [`assets/sass`](./assets/sass) directory. There is also a small amount of JavaScript logic for the site in [`assets/js/app.js`](./assets/js/app.js). ## Publishing the website The Harbor website is published automatically on the [Netlify](https://netlify.com) platform. Whenever changes are merged, the site is re-built and re-deployed, usually within about one minute. ## Run the Harbor website locally ### Step 1: Clone project ```sh git clone https://github.com/goharbor/website.git cd website ``` ## Step 2: Load documentation content The Markdown content for the Harbor [docs](https://goharbor.io/docs) is drawn from the [`docs`](./docs) folder and the `release-X` branches. To pull that content into your local website repo: ```sh make prepare ``` This copies the `docs` directory and the `release-X` branches into this repo's [`content`](./content) folder, separated by versions, where it can be processed by Hugo. ## Step 3: Install npm dependencies ```sh npm i ``` ## Step 4: Run Hugo in server mode ```sh make serve ``` This starts up the local Hugo server on http://localhost:1313. As you make changes, the site refreshes automatically in your browser. ## Checking links To run the link checker for the Harbor website: ```sh make check-internal-links ``` This command builds the site (including drafts and future content), downloads the [htmltest](https://github.com/wjdp/htmltest) link checker into your local directory, and runs the checker in accordance with the configuration specified in [`.htmltest.yml`](./.htmltest.yml). Only internal links are checked and all errors are piped to stdout. ## License [](https://app.fossa.com/projects/git%2Bgithub.com%2Fgoharbor%2Fwebsite?ref=badge_large) --- ## File: docs/README.md Harbor Documentation This is the main table of contents for the Harbor 2.1.x documentation. ## Harbor Installation and Configuration This section describes how to install Harbor and perform the required initial configurations. These day 1 operations are performed by the Harbor Administrator. - [Introduction](install-config/_index.md) - [Test Harbor with the Demo Server](install-config/demo-server.md) - [Harbor Compatibility List](install-config/harbor-compatibility-list.md) - [Harbor Installation Prerequisites](install-config/installation-prereqs.md) - [Download the Harbor Installer](install-config/download-installer.md) - [Configure HTTPS Access to Harbor](install-config/configure-https.md) - [Configure the Harbor YML File](install-config/configure-yml-file.md) - [Run the Installer Script](install-config/run-installer-script.md) - [Deploying Harbor with High Availability via Helm](install-config/harbor-ha-helm.md) - [Troubleshooting Harbor Installation](install-config/troubleshoot-installation.md) - [Reconfigure Harbor and Manage the Harbor Lifecycle](install-config/reconfigure-manage-lifecycle.md) - [Customize the Harbor Token Service](install-config/customize-token-service.md) - [Configure Harbor Settings at the Command Line](install-config/configure-system-settings-cli.md) ## Harbor Administration This section describes how to use and maintain Harbor after deployment. These day 2 operations are performed by the Harbor Administrator. - [Introduction](administration/_index.md) - [Configuring Authentication](administration/configure-authentication/_index.md) - [Configure Database Authentication](administration/configure-authentication/db-auth.md) - [Configure LDAP/Active Directory Authentication](administration/configure-authentication/ldap-auth.md) - [Configure OIDC Provider Authentication](administration/configure-authentication/oidc-auth.md) - [Managing Users](administration/managing-users/_index.md) - [User Permissions By Role](administration/managing-users/user-permissions-by-role.md) - [Create User Accounts in Database Mode](administration/managing-users/create-users-db.md) - [Configure Global Settings](administration/general-settings/_index.md) - [Configure Project Quotas](administration/configure-project-quotas/_index.md) - [Configuring Replication](administration/configuring-replication/_index.md) - [Create Replication Endpoints](administration/configuring-replication/create-replication-endpoints.md) - [Create Replication Rules](administration/configuring-replication/create-replication-rules.md) - [Manage Replications](administration/configuring-replication/manage-replications.md) - [Vulnerability Scanning](administration/vulnerability-scanning/_index.md) - [Connect Harbor to Additional Vulnerability Scanners](administration/vulnerability-scanning/pluggable-scanners.md) - [Scan Individual Images](administration/vulnerability-scanning/scan-individual-image.md) - [Scan All Images](administration/vulnerability-scanning/scan-all-images.md) - [Schedule Scans](administration/vulnerability-scanning/schedule-scans.md) - [Import Vulnerability Data to an Offline Harbor instance](administration/vulnerability-scanning/import-vulnerability-data.md) - [Configure System-Wide CVE Allowlists](administration/vulnerability-scanning/configure-system-allowlist.md) - [Garbage Collection](administration/garbage-collection/_index.md) - [Upgrade Harbor and Migrate Data](administration/upgrade/upgrade-migrate-data.md) - [Upgrading Harbor Deployed with Helm](administration/upgrade/helm-upgrade.md) - [Roll Back an Upgrade](administration/upgrade/roll-back-upgrade.md) - [Test Harbor Upgrade](administration/upgrade/upgrade-test.md) - [Configure P2P Preheat](administration/p2p-preheat/_index.md) - [User-defined OCI artifact](administration/user-defined-OCI-artifact/_index.md) ## Working with Harbor Projects This section describes how users with the developer, maintainer, and project administrator roles manage and participate in Harbor projects. - [Introduction](working-with-projects/_index.md) - [Create Projects](working-with-projects/create-projects/_index.md) - [Assign Users to a Project](working-with-projects/add-users.md) - [Project Configuration](working-with-projects/project-configuration/_index.md) - [Access and Search Project Logs](working-with-projects/access-project-logs.md) - [Create Robot Accounts](working-with-projects/create-robot-accounts.md) - [Configure Webhook Notifications](working-with-projects/configure-webhooks.md) - [Configure a Per-Project CVE Allowlist](working-with-projects/configure-project-allowlist.md) - [Implementing Content Trust](working-with-projects/implementing-content-trust.md) - [Working with Images, Tags, and Helm Charts](working-with-projects/working-with-images.md) - [Pulling and Pushing Images](working-with-projects/pulling-pushing-images.md) - [Create Labels](working-with-projects/create-labels.md) - [Retag Images](working-with-projects/retagging-images.md) - [Create Tag Retention Rules](working-with-projects/create-tag-retention-rules.md) - [Create Tag Immutability Rules](working-with-projects/create-tag-immutability-rules.md) - [Manage Kubernetes Packages with Helm Charts](working-with-projects/managing-helm-charts.md) - [Preheat Images](working-with-projects/working-with-images/preheat-images.md) - [Using API Explorer](working-with-projects/using-api-explorer/_index.md) ## Build, Customize, and Contribute to Harbor This section describes how developers can build from Harbor source code, customize their deployments, and contribute to the open-source Harbor project. - [Build Harbor from Source Code](build-customize-contribute/compile-guide.md) - [Developing the Harbor Frontend](build-customize-contribute/ui-contribution-get-started.md) - [Customize the Harbor Look & Feel ](build-customize-contribute/customize-look-feel.md) - [Developing for Internationalization](build-customize-contribute/developer-guide-i18n.md) - [Using Make](build-customize-contribute/use-make.md) - [View and test Harbor REST API via Swagger](build-customize-contribute/configure-swagger.md) - [Registry Landscape](build-customize-contribute/registry-landscape.md) - [E2E Test Scripting Guide](build-customize-contribute/e2e_api_python_based_scripting_guide.md) See also the list of [Articles from the Harbor Community](https://github.com/goharbor/harbor/blob/master/docs/README.md#articles-from-the-community).