mirror of
https://github.com/goharbor/harbor.git
synced 2024-12-18 14:47:38 +01:00
Merge pull request #10493 from stuclem/sclements-remove-old-doc
Finalizing the doc reorg and removing old content
This commit is contained in:
xaleeks
GitHub
commit
d1df285b7e
3
docs/1.10/README.md
Normal file
3
docs/1.10/README.md
Normal file
@ -0,0 +1,3 @@
|
||||
# Harbor Documentation
|
||||
|
||||
You access the Harbor documentation from the [Table of Contents](index.md).
|
||||
@ -18,7 +18,7 @@ In database authentication mode, user accounts are stored in the local database.
|
||||
|
||||
|
||||
|
||||
If you enable self registration option, users can register themselves in Harbor. Self-registration is disabled by default. If you enable self-registration, unregistered users can sign up for a Harbor account by clicking **Sign up for an account** in the Harbor log in page.
|
||||
If you enable the self registration option, users can register themselves in Harbor. Self-registration is disabled by default. If you enable self-registration, unregistered users can sign up for a Harbor account by clicking **Sign up for an account** in the Harbor log in page.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ Because the users are managed by the OIDC provider, self-registration, creating
|
||||
You must configure your OIDC provider so that you can use it with Harbor. For precise information about how to perform these configurations, see the documentation for your OIDC provider.
|
||||
|
||||
- Set up the users and groups that will use the OIDC provider to log in to Harbor. You do not need to assign any specific OIDC roles to users or groups as these do not get mapped to Harbor roles.
|
||||
- The URL of the OIDC provider endpoint, known as the Authorization Server in OAuth terminology, must service the well-known URI for its configuration document. For more information about the configuration document, see the [OpenID documentation] (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest).
|
||||
- The URL of the OIDC provider endpoint, known as the Authorization Server in OAuth terminology, must service the well-known URI for its configuration document. For more information about the configuration document, see the [OpenID documentation](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest).
|
||||
- To manage users by using OIDC groups, create a custom group claim that contains all of the user groups that you want to register in Harbor. The group claim must be mapped in the ID token that is sent to Harbor when users log in. You can enable the `memberof` feature on the OIDC provider. With the `memberof` feature, the OIDC user entity's `memberof` attribute is updated when the group entity's `member` attribute is updated, for example by adding or removing an OIDC user from the OIDC group.
|
||||
- Register Harbor as a client application with the OIDC provider. Associate Harbor's callback URI to the client application as a `redirectURI`. This is the address to which the OIDC provider sends ID tokens.
|
||||
|
||||
|
||||
@ -2,16 +2,7 @@
|
||||
|
||||
----------
|
||||
|
||||
# Configure Project Settings
|
||||
|
||||
You can configure Harbor so that only system administrators can create projects, and set limits on the amounts of resources that projects can consume.
|
||||
|
||||
## Set Who Can Create Projects
|
||||
|
||||
Use the **Project Creation** drop-down menu to set which users can create projects. Select **Everyone** to allow all users to create projects. Select **Admin Only** to allow only users with the Harbor system administrator role to create projects.
|
||||
|
||||
|
||||
## Set Project Quotas
|
||||
# Configure Project Quotas
|
||||
|
||||
To exercise control over resource use, as a Harbor system administrator you can set quotas on projects. You can limit the number of tags that a project can contain and limit the amount of storage capacity that a project can consume. You can set default quotas that apply to all projects globally.
|
||||
|
||||
@ -10,4 +10,9 @@ There might be some delay during replication based on the condition of the netwo
|
||||
|
||||
- [Create Replication Endpoints](create_replication_endpoints.md)
|
||||
- [Create Replication Rules](create_replication_rules.md)
|
||||
- [Manage Replications](manage_replications.md)
|
||||
- [Running Replication Manually](manage_replications.md)
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Creating Replication Endpoints
|
||||
|
||||
To replicate image repositories from one instance of Harbor to another Harbor or non-Harbor registry, you first create replication endpoints.
|
||||
@ -44,4 +48,9 @@ To replicate image repositories from one instance of Harbor to another Harbor or
|
||||
## Managing Registries
|
||||
You can list, add, edit and delete registries under `Administration->Registries`. Only registries which are not referenced by any rules can be deleted.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Creating a Replication Rule
|
||||
|
||||
A replication endpoint must exist before you create a replication rule. To create an endpoint, follow the instructions in [Creating Replication Endpoints](create_replication_endpoints.md).
|
||||
@ -56,3 +60,8 @@ A replication endpoint must exist before you create a replication rule. To creat
|
||||
|
||||
1. Optionally select the Override checkbox to force replicated resources to replace resources at the destination with the same name.
|
||||
1. Click **Save** to create the replication rule.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Running Replication Manually
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
@ -16,4 +20,9 @@
|
||||
|
||||
To edit or delete a replication rule, select the replication rule in the **Replications** view and click **Edit** or **Delete**. Only rules which have no executions in progress can be edited deleted.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
When you delete images from Harbor, space is not automatically freed up. You must run garbage collection to free up space by removing blobs that are no longer referenced by a manifest from the file system.
|
||||
|
||||
### Run Garbage Collection
|
||||
## Run Garbage Collection
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Garbage Collection**.
|
||||
@ -18,7 +18,7 @@ When you run garbage collection, Harbor goes into read-only mode. All modificati
|
||||
|
||||
To avoid triggering the garbage collection process too frequently, the availability of the **GC Now** button is restricted. Garbage collection can be only run once per minute.
|
||||
|
||||
### Schedule Garbage Collection
|
||||
## Schedule Garbage Collection
|
||||
|
||||
1. Expand **Administration**, and select **Garbage Collection**.
|
||||
1. Select the **'Garbage Collection'** tab.
|
||||
|
||||
@ -4,19 +4,22 @@
|
||||
|
||||
# Configure Global Settings
|
||||
|
||||
You can configure Harbor to connect to an email server, and set the registry in read-only mode.
|
||||
You can configure Harbor to connect to an email server, set the registry in read-only mode, and configure Harbor so that only system administrators can create projects.
|
||||
|
||||
## Configure an Email Server
|
||||
|
||||
You can change Harbor's email settings, the mail server is used to send out responses to users who request to reset their password.
|
||||
You can configure Harbor to connect to an email server. The email server is only used to send out responses to users who request to reset their password.
|
||||
|
||||
|
||||
|
||||
## Make the Registry Read Only
|
||||
|
||||
You can change Harbor's registry read only settings, read only mode will allow 'docker pull' while preventing 'docker push' and the deletion of repository and tag.
|
||||
|
||||
You can set Harbor to read-only mode. In read-only mode, Harbor allows `docker pull` but prevents `docker push` and the deletion of repositories and tags.
|
||||
|
||||
|
||||
|
||||
If it set to true, deleting repositories, tags and pushing images are not permitted.
|
||||
|
||||
If it set to true, deleting repository, tag and pushing image will be disabled.
|
||||
|
||||
|
||||
|
||||
@ -27,6 +30,11 @@ The push refers to a repository [10.117.169.182/demo/ubuntu]
|
||||
denied: The system is in read only mode. Any modification is prohibited.
|
||||
```
|
||||
|
||||
## Set Who Can Create Projects
|
||||
|
||||
Use the **Project Creation** drop-down menu to set which users can create projects. Select **Everyone** to allow all users to create projects. Select **Admin Only** to allow only users with the Harbor system administrator role to create projects.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -6,12 +6,12 @@ The operations that are performed by the Harbor system administrator are the fol
|
||||
|
||||
- Select database, LDAP/Active Directory, or OIDC based authentication. For information, see [Configuring Authentication](configure_authentication/configure_authentication.md).
|
||||
- Add users in database authentication mode and assign the system administrator role to other users. For information, see [Role Based Access Control](managing_users/rbac.md).
|
||||
- Configure general system settings, including setting up an email server and setting the registry to read-only mode. For information, see [Configure Global Settings](general_settings.md).
|
||||
- Configure how projects are created, and apply resource quotas to projects. For information, see [Configure Project Settings](configure_project_settings.md).
|
||||
- Configure global settings, such as configuring an email server, setting the registry to read-only mode, and restriction who can create projects. For information, see [Configure Global Settings](general_settings.md).
|
||||
- Apply resource quotas to projects. For information, see [Configure Project Quotas](configure_project_quotas.md).
|
||||
- Set up replication of images between Harbor and another Harbor instance or a 3rd party replication target. For information, see [Configuring Replication](configuring_replication/configuring_replication.md).
|
||||
- Set up vulnerability scanners to check the images in the registry for CVE vulnerabilities. For information, see [Vulnerability Scanning](vulnerability_scanning/vulnerability_scanning.md).
|
||||
- Perform garbage collection, to remove unnecessary data from Harbor. For information, see [Garbage Collection](garbage_collection.md).
|
||||
- Upgrade Harbor when a new version becomes available. For information, see [Upgrading Harbor](upgrade/upgrade_harbor.md).
|
||||
- Upgrade Harbor when a new version becomes available. For information, see [Upgrading Harbor](upgrade/upgrade_migrate_data.md).
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ In database authentication mode, the Harbor system administrator creates user ac
|
||||
- The email address is used for password recovery
|
||||
- The password must contain at least 8 characters with 1 lowercase letter, 1 uppercase letter and 1 numeric character
|
||||
|
||||
If users forget their password, there is a **Forgot Password** in the Harbor log in page.
|
||||
If users forget their password, there is a **Forgot Password** in the Harbor log in page. To use this feature, you must [configure an email server](../general_settings.md).
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# User Permissions By Role
|
||||
|
||||
Users have different abilities depending on the role they in a project.
|
||||
@ -55,4 +59,8 @@ The following table depicts the various user permission levels in a project.
|
||||
| See project quotas | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Edit project quotas * | | | | | |
|
||||
|
||||
* Only the Harbor system administrator can edit project quotas and add new scanners.
|
||||
* Only the Harbor system administrator can edit project quotas and add new scanners.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
74
docs/1.10/administration/upgrade/helm_upgrade.md
Normal file
74
docs/1.10/administration/upgrade/helm_upgrade.md
Normal file
@ -0,0 +1,74 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Upgrading Harbor Deployed with Helm
|
||||
|
||||
This guide is used to upgrade Harbor deployed by chart since version 0.3.0.
|
||||
|
||||
## Notes
|
||||
|
||||
- As the database schema may change between different versions of Harbor, there is a progress to migrate the schema during the upgrade and the downtime cannot be avoid
|
||||
- The database schema cannot be downgraded automatically, so the `helm rollback` is not supported
|
||||
|
||||
## Upgrade
|
||||
|
||||
### 1. Backup database
|
||||
|
||||
Backup the database used by Harbor in case the upgrade process fails.
|
||||
|
||||
### 2. Download new chart
|
||||
|
||||
Download the latest version of Harbor chart.
|
||||
|
||||
### 3. Configure new chart
|
||||
|
||||
Configure the new chart to make sure that the configuration items have the same values with the old one.
|
||||
|
||||
> Note: if TLS is enabled and the certificate is generated by chart automatically, a new certificate will be generated and overwrite the old one during the upgrade, this may cause some issues if you have distributed the certificate. You can follow the below steps to configure the new chart to use the old certificate:
|
||||
|
||||
1) Get the secret name which certificate is stored in:
|
||||
|
||||
```bash
|
||||
kubectl get secret
|
||||
```
|
||||
|
||||
Find the secret whose name ends with `-harbor-ingress` (expose service via `Ingress`) or `-harbor-nginx`(expose service via `ClusterIP` or `NodePort`)
|
||||
|
||||
2) Export the secret as yaml file:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl get secret <secret-name-from-step-1> -o yaml > secret.yaml
|
||||
```
|
||||
|
||||
|
||||
|
||||
3) Rename the secret by setting `metadata.name` in `secret.yaml`
|
||||
|
||||
4) Create a new secret:
|
||||
|
||||
```bash
|
||||
kubectl create -f secret.yaml
|
||||
```
|
||||
|
||||
5) Configure the chart to use the new secret by setting `expose.tls.secretName` as the value you set in step **3**
|
||||
|
||||
### 4. Upgrade
|
||||
|
||||
Run upgrade command:
|
||||
|
||||
```bash
|
||||
helm upgrade release-name --force .
|
||||
```
|
||||
|
||||
> The `--force` is necessary if upgrade from version 0.3.0 due to issue [#30](https://github.com/goharbor/harbor-helm/issues/30).
|
||||
|
||||
## Known issues
|
||||
|
||||
- The job logs will be lost if you upgrade from version 0.3.0 as the logs are store in a `emptyDir` in 0.3.0.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -1,6 +1,12 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Roll Back from an Upgrade
|
||||
|
||||
If, for any reason, you want to roll back to the previous version of Harbor, perform the following steps:
|
||||
If, for any reason, you need to roll back to the previous version of Harbor, perform the following steps.
|
||||
|
||||
**NOTE**: To roll back from an upgrade, you must have backed up the previous version of Harbor. For information about backing up Harbor before an upgrade, see [Upgrade Harbor and Migrate Data](upgrade_migrate_data.md).
|
||||
|
||||
1. Stop and remove the current Harbor service if it is still running.
|
||||
|
||||
@ -15,20 +21,25 @@ If, for any reason, you want to roll back to the previous version of Harbor, per
|
||||
rm -rf harbor
|
||||
```
|
||||
|
||||
3. Restore the older version package of Harbor.
|
||||
3. Restore the older version of Harbor.
|
||||
|
||||
```sh
|
||||
mv /my_backup_dir/harbor harbor
|
||||
```
|
||||
|
||||
4. Restore database, copy the data files from backup directory to you data volume, by default `/data/database`.
|
||||
4. To restore the database, copy the data files from the backup directory to your data volume, which by default is `/data/database`.
|
||||
|
||||
5. Restart Harbor service using the previous configuration.
|
||||
If previous version of Harbor was installed by a release build:
|
||||
5. Restart the Harbor service using the previous configuration.
|
||||
|
||||
If the previous version of Harbor was installed by a release build:
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
./install.sh
|
||||
```
|
||||
|
||||
**NOTE**: While you can roll back an upgrade to the state before you started the upgrade, Harbor does not support downgrades.
|
||||
**NOTE**: While you can roll back an upgrade to the state before you started the upgrade, Harbor does not support downgrades.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -1,4 +0,0 @@
|
||||
# Upgrading Harbor
|
||||
|
||||
- [Upgrade Harbor and Migrate Data](upgrade_migrate_data.md)
|
||||
- [Roll Back an Upgrade](roll_back_upgrade.md)
|
||||
@ -1,71 +1,73 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Upgrade Harbor and Migrate Data
|
||||
|
||||
This guide covers upgrade and migration to version 1.9.0. This guide only covers migration from v1.7.x and later to the current version. If you are upgrading from an earlier version, refer to the migration guide in the `release-1.7.0` branch to upgrade to v1.7.x first, then follow this guide to perform the migration to this version.
|
||||
This guide covers upgrade and migration to version 1.10.0. This guide only covers migration from v1.8.x and later to the current version. If you are upgrading from an earlier version, refer to the migration guide in the `release-1.8.0` branch to upgrade to v1.8.x first, then follow this guide to perform the migration to this version.
|
||||
|
||||
When upgrading an existing Harbor 1.7.x instance to a newer version, you might need to migrate the data in your database and the settings in `harbor.cfg`.
|
||||
When upgrading an existing Harbor instance to a newer version, you might need to migrate the data in your database and the settings in `harbor.cfg`.
|
||||
Since the migration might alter the database schema and the settings of `harbor.cfg`, you should **always** back up your data before any migration.
|
||||
|
||||
**NOTES:**
|
||||
|
||||
- Again, you must back up your data before any data migration.
|
||||
- Since v1.8.0, the configuration of Harbor has changed to a `.yml` file. If you are upgrading from 1.7.x, the migrator will transform the configuration file from `harbor.cfg` to `harbor.yml`. The command will be a little different to perform this migration, so make sure you follow the steps below.
|
||||
- In version 1.9.0, some containers are started by `non-root`. This does not pose problems if you are upgrading an officially released version of Harbor, but if you have deployed a customized instance of Harbor, you might encounter permission issues.
|
||||
- In previous releases, user roles took precedence over group roles in a project. In this version, user roles and group roles are combined so that the user has whichever set of permissions is highest. This might cause the roles of certain users to change during upgrade.
|
||||
- With the introduction of storage and artifact quotas in version 1.9.0, migration from 1.7.x and 1.8.x might take a few minutes. This is because the `core` walks through all blobs in the registry and populates the database with information about the layers and artifacts in projects.
|
||||
- With the introduction of storage and artifact quotas in version 1.9.0, migration from 1.8.x might take a few minutes. This is because the `core` walks through all blobs in the registry and populates the database with information about the layers and artifacts in projects.
|
||||
- With the introduction of storage and artifact quotas in version 1.9.0, replication between version 1.9.0 and a previous version of Harbor does not work. You must upgrade all Harbor nodes to 1.9.0 if you have configured replication between them.
|
||||
|
||||
## Upgrading Harbor and Migrating Data
|
||||
|
||||
1. Log in to the host that Harbor runs on, stop and remove existing Harbor instance if it is still running:
|
||||
1. Log in to the Harbor host and, if it is still running, stop and remove the existing Harbor instance.
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
docker-compose down
|
||||
```
|
||||
|
||||
2. Back up Harbor's current files so that you can roll back to the current version if necessary.
|
||||
1. Back up Harbor's current files so that you can roll back to the current version if necessary.
|
||||
|
||||
```sh
|
||||
mv harbor /my_backup_dir/harbor
|
||||
```
|
||||
|
||||
Back up database (by default in directory `/data/database`)
|
||||
1. Back up the database, which by default is in the directory `/data/database`.
|
||||
|
||||
```sh
|
||||
cp -r /data/database /my_backup_dir/
|
||||
```
|
||||
|
||||
3. Get the latest Harbor release package from Github:
|
||||
[https://github.com/goharbor/harbor/releases](https://github.com/goharbor/harbor/releases)
|
||||
1. Get the latest Harbor release package from [https://github.com/goharbor/harbor/releases](https://github.com/goharbor/harbor/releases).
|
||||
1. Before upgrading Harbor, perform migration.
|
||||
|
||||
4. Before upgrading Harbor, perform migration first. The migration tool is delivered as a docker image.
|
||||
|
||||
You can pull the image from docker hub. Replace [tag] with the release version of Harbor (e.g. v1.5.0) in the below command:
|
||||
The migration tool is delivered as a docker image. You can pull the image from docker hub. Replace [tag] with the new Harbor version, for example v1.10.0, in the following command:
|
||||
|
||||
```sh
|
||||
docker pull goharbor/harbor-migrator:[tag]
|
||||
```
|
||||
|
||||
Alternatively, if you are using an offline installer package you can load it from the image tarball included in the offline installer package. Replace [version] with the release version of Harbor (e.g. v1.5.0) in the below command:
|
||||
Alternatively, if you are using an offline installer package, you can load it from the image tarball that is included in the offline installer package. Replace [tag] with the new Harbor version, for example v1.10.0, in the following command:
|
||||
|
||||
```sh
|
||||
tar zxf <offline package>
|
||||
docker image load -i harbor/harbor.[version].tar.gz
|
||||
```
|
||||
|
||||
5. If you are current version is v1.7.x or earlier, i.e. migrate config file from `harbor.cfg` to `harbor.yml`.
|
||||
|
||||
**NOTE:** You can find the ${harbor_yml} in the extracted installer you got in step `3`, after the migration the file `harbor.yml`
|
||||
in that path will be updated with the values from ${harbor_cfg}
|
||||
|
||||
```sh
|
||||
docker run -it --rm -v ${harbor_cfg}:/harbor-migration/harbor-cfg/harbor.yml -v ${harbor_yml}:/harbor-migration/harbor-cfg-out/harbor.yml goharbor/harbor-migrator:[tag] --cfg up
|
||||
```
|
||||
|
||||
Otherwise, If your version is 1.8.x or higher, just upgrade the `harbor.yml` file.
|
||||
1. Upgrade the `harbor.yml` file.
|
||||
|
||||
```sh
|
||||
docker run -it --rm -v ${harbor_yml}:/harbor-migration/harbor-cfg/harbor.yml goharbor/harbor-migrator:[tag] --cfg up
|
||||
```
|
||||
|
||||
**NOTE:** The schema upgrade and data migration of the database is performed by core when Harbor starts, if the migration fails, please check the log of core to debug.
|
||||
**NOTE:** The schema upgrade and data migration of the database is performed by core when Harbor starts. If the migration fails, check the core log to debug.
|
||||
|
||||
6. Under the directory `./harbor`, run the `./install.sh` script to install the new Harbor instance. If you choose to install Harbor with components such as Notary, Clair, and chartmuseum, refer to [Installation & Configuration Guide](../docs/installation_guide.md) for more information.
|
||||
1. In the `./harbor` directory, run the `./install.sh` script to install the new Harbor instance.
|
||||
|
||||
To install Harbor with components such as Notary, Clair, and chartmuseum, see [Run the Installer Script](../../install_config/run_installer_script.md) for more information.
|
||||
|
||||
If you need to roll back to the previous version of Harbor, see [Roll Back from an Upgrade](roll_back_upgrade.md).
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
41
docs/1.10/administration/upgrade/upgradetest.md
Normal file
41
docs/1.10/administration/upgrade/upgradetest.md
Normal file
@ -0,0 +1,41 @@
|
||||
# Test Harbor Upgrade
|
||||
|
||||
## Prepare data
|
||||
1. Add user usera userb userc userd usere, set usera userb as system admin.
|
||||
2. Create project projecta projectc as private, create projectb as public.
|
||||
3. Add usera as projecta's admin, userc as developer, and userd as guest. Do the same to projectb and projectc.
|
||||
4. Login harbor as usera, push an unsigned image into projecta, then push a signed image to projecta.
|
||||
5. Login harbor as userc, push an unsigned image into projecta, then push a signed image to projeca.
|
||||
6. Login harbor as userd, push each image one time.
|
||||
7. Repeat 4 5 6 to projectb and projectc.
|
||||
8. Add one endpoint to harbor.
|
||||
9. Add an immediate replication rule to projeca, a schedule rule to projectb, a manual rule to projectc, trigger each rule one time.
|
||||
10. Add 5 system label syslabel1 to syslabel5 and tag syslabel1 and syslabel2 to all unsigned image.
|
||||
11. In each project add 5 project label projlabela to projlabele, add projlabela projlabelb and projlabelc to signed image.
|
||||
12. Trigger one scan all job to scan all images.(For clair enabled instance)
|
||||
13. Update project publicly, content trust, severity and scanning settings.
|
||||
14. Update Harbor email, token expire read only and scan settings.
|
||||
15. Update repository info.
|
||||
**NOTE**: Create user step is not needed if auth mode is LDAP.
|
||||
|
||||
# Upgrade
|
||||
|
||||
## Follow the upgrade guide
|
||||
1. Run db migrator image to backup database.
|
||||
2. Run db migrator image to migrate database.
|
||||
3. Install new version harbor.
|
||||
|
||||
# After upgrade
|
||||
|
||||
1. Confirm users are exist and available(No need for VIC and LDAP Mode).
|
||||
2. Confirm users have the correct role.
|
||||
3. Confirm labels are existing and labeled correct.(No need for VIC)
|
||||
4. Confirm notary signature correct.
|
||||
5. Confirm endpoint exist.
|
||||
6. Confirm replication rule exist and works well.
|
||||
7. Confirm project level settings(publicly, content trust, scan) same as before.
|
||||
8. Confirm system level settings(email token expire scan) same as before.
|
||||
9. Confirm scan result the same as before upgrade.
|
||||
10. Confirm access log the same as before upgrade.
|
||||
11. Confirm repository info the same as before.
|
||||
12. Confirm other image metadata(e.g. author, size) the same as before.
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Configure System-Wide CVE Whitelists
|
||||
|
||||
When you run vulnerability scans, images that are subject to Common Vulnerabilities and Exposures (CVE) are identified. According to the severity of the CVE and your security settings, these images might not be permitted to run. As a Harbor system administrator, you can create whitelists of CVEs to ignore during vulnerability scanning.
|
||||
@ -21,3 +25,7 @@ System-wide CVE whitelists apply to all of the projects in a Harbor instance.
|
||||
After you have created a system whitelist, you can remove CVE IDs from the list by clicking the delete button next to it in the list. You can click **Add** to add more CVE IDs to the system whitelist.
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
@ -1,22 +1,19 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Import Vulnerability Data to an Offline Harbor instance
|
||||
|
||||
Harbor has integrated with Clair to scan vulnerabilities in images. When Harbor is installed in an environment without internet connection, Clair cannot fetch data from the public vulnerability database. Under this circumstance, Harbor administrator needs to manually update the Clair database.
|
||||
If Harbor is installed in an environment without an internet connection, Clair cannot fetch data from the public vulnerability database. In this case, the Harbor administrator must update the Clair database manually.
|
||||
|
||||
This document provides step-by-step instructions on updating Clair vulnerability database in Harbor.
|
||||
## Preparation
|
||||
|
||||
**NOTE:** Harbor does not ship with any vulnerability data. For this reason, if Harbor cannot connect to Internet, the administrator must manually import vulnerability data to Harbor by using instructions given in this document.
|
||||
- You have an instance of Clair that has an internet connection. If you have another instance of Harbor that has internet access, this also works.
|
||||
- Check whether your Clair instance has already updated its vulnerability database to the latest version.
|
||||
|
||||
### Preparation
|
||||
|
||||
A. You need to install an instance of Clair with internet connection. If you have another instance of Harbor with internet access, it also works.
|
||||
|
||||
B. Check whether your Clair instance has already updated the vulnerability database to the latest version. If it has not, wait for Clair to get the data from public endpoints.
|
||||
|
||||
- Use command `docker ps` to find out the container id of Clair.
|
||||
|
||||
- Run command `docker logs container_id` to check the log of the Clair container. If you are using Harbor you can find the latest Clair log under /var/log/harbor/2017-xx-xx/clair.log
|
||||
|
||||
- Look for logs that look like the below:
|
||||
1. Use `docker ps` to find out the container ID of the Clair service.
|
||||
1. Run `docker logs <container_id>` to check the log of the Clair container. If you are using Harbor you can find the latest Clair logs under `/var/log/harbor/2017-xx-xx/clair.log`.
|
||||
1. Look for logs that look like the following:
|
||||
```
|
||||
Jul 3 20:40:45 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:40:45.890364","updater name":"rhel"}
|
||||
Jul 3 20:40:46 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:40:46.768924","updater name":"alpine"}
|
||||
@ -27,43 +24,50 @@ B. Check whether your Clair instance has already updated the vulnerability datab
|
||||
Jul 4 00:26:18 172.18.0.1 clair[3516]: {"Event":"adding metadata to vulnerabilities","Level":"info","Location":"updater.go:253","Time":"2017-07-04 07:26:18.060810"}
|
||||
Jul 4 00:38:05 172.18.0.1 clair[3516]: {"Event":"update finished","Level":"info","Location":"updater.go:198","Time":"2017-07-04 07:38:05.251580"}
|
||||
```
|
||||
- The phrase "finished fetching" indicates that Clair has finished a round of vulnerability update from an endpoint. Please make sure all five endpoints (rhel, alpine, oracle, debian, ubuntu) are updated correctly.
|
||||
The phrase `finished fetching` indicates that Clair has finished a round of vulnerability updates from an endpoint. Make sure all of the `rhel`, `alpine`, `oracle`, `debian`, and `ubuntu` endpoints are updated correctly. If they have not, wait for Clair to get the data.
|
||||
|
||||
## Harbor version < 1.6
|
||||
## Dump Vulnerability Data
|
||||
|
||||
If you're using a version of Harbor prior to 1.6, you can access the correct instructions for your version using the following URL.
|
||||
https://github.com/goharbor/harbor/blob/v\<VERSION NUMBER>/docs/import_vulnerability_data.md
|
||||
1. Log in to the host, that is connected to Internet, on which the Postgres Clair database is running.
|
||||
1. Dump Clair's vulnerability database by running the following commands.
|
||||
|
||||
## Harbor version >= 1.6
|
||||
**NOTE**: The container name `clair-db` is a placeholder for the database container used by the internet-connected instance of Clair.
|
||||
|
||||
Databased were consolidated in version 1.6 which moved the clair database to the harbor-db container and removed the clair-db container.
|
||||
```
|
||||
$ docker exec clair-db /bin/sh -c "pg_dump -U postgres -a -t feature -t keyvalue -t namespace -t schema_migrations -t vulnerability -t vulnerability_fixedin_feature" > vulnerability.sql
|
||||
```
|
||||
|
||||
```
|
||||
$ docker exec clair-db /bin/sh -c "pg_dump -U postgres -c -s" > clear.sql
|
||||
```
|
||||
|
||||
### Dumping vulnerability data
|
||||
The files `vulnerability.sql` and `clear.sql` are generated.
|
||||
|
||||
- Log in to the host (that is connected to Internet) where Clair database (Postgres) is running.
|
||||
- Dump Clair's vulnerability database by the following commands, two files (`vulnerability.sql` and `clear.sql`) are generated:
|
||||
## Back Up the Harbor Clair Database
|
||||
|
||||
_NOTE: The container name 'clair-db' is a placeholder for the db container used by the internet connected instance of clair_
|
||||
|
||||
```
|
||||
$ docker exec clair-db /bin/sh -c "pg_dump -U postgres -a -t feature -t keyvalue -t namespace -t schema_migrations -t vulnerability -t vulnerability_fixedin_feature" > vulnerability.sql
|
||||
$ docker exec clair-db /bin/sh -c "pg_dump -U postgres -c -s" > clear.sql
|
||||
```
|
||||
|
||||
### Back up Harbor's Clair database
|
||||
Before importing the data, it is strongly recommended to back up the Clair database in Harbor.
|
||||
|
||||
```
|
||||
$ docker exec harbor-db /bin/sh -c "pg_dump -U postgres -c" > all.sql
|
||||
```
|
||||
|
||||
### Update Harbor's Clair database
|
||||
Copy the `vulnerability.sql` and `clear.sql` to the host where Harbor is running on. Run the below commands to import the data to Harbor's Clair database:
|
||||
## Update the Harbor Clair Database
|
||||
|
||||
```
|
||||
$ docker exec -i harbor-db psql -U postgres < clear.sql
|
||||
$ docker exec -i harbor-db psql -U postgres < vulnerability.sql
|
||||
```
|
||||
1. Copy the `vulnerability.sql` and `clear.sql` files to the host on which Harbor is running.
|
||||
1. Run the following commands to import the data to the Harbor Clair database:
|
||||
|
||||
### Rescanning images
|
||||
After importing the data, trigger the scanning process in the administrator's web UI: **Administration**->**Configuration**->**Vulnerability**->**SCAN NOW**. Harbor reflects the new changes after the scanning is completed. (Otherwise the summary of the image vulnerabilities will not be displayed correctly.)
|
||||
```
|
||||
$ docker exec -i harbor-db psql -U postgres < clear.sql
|
||||
```
|
||||
```
|
||||
$ docker exec -i harbor-db psql -U postgres < vulnerability.sql
|
||||
```
|
||||
|
||||
## Rescan the Images
|
||||
|
||||
After importing the data, trigger the scanning process in the Harbor interface. For information about running a scan, see [Scan All Images](scan_all_images.md).
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Connect Harbor to Additional Vulnerability Scanners
|
||||
|
||||
To connect Harbor to additional vulnerability scanners, you must install and configure an instance of the additional scanner according to the scanner vendor's requirements. The scanner must expose an API endpoint to allow Harbor to trigger the scan process or get reports. You can deploy multiple different scanners, and multiple instances of the same type of scanner.
|
||||
@ -36,4 +40,8 @@ Depending on the scanner that you use, once the database is ready, the timestamp
|
||||
|
||||
Until the database has been fully populated, the timestamp is replaced by a warning symbol. When the database is ready, you can scan images individually or scan all images across all projects.
|
||||
|
||||
If your Harbor instance is not connected to the external internet, you must manually update the vulnerability metadata. For information about how to update Clair manually, see [Import Vulnerability Data to an Offline Harbor instance](import_vulnerability_data.md).
|
||||
If your Harbor instance is not connected to the external internet, you must manually update the vulnerability metadata. For information about how to update Clair manually, see [Import Vulnerability Data to an Offline Harbor instance](import_vulnerability_data.md).
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Scan All Images
|
||||
|
||||
In addition to scanning individual images in projects, you can run global scans on all of the images in a Harbor instance, across all projects.
|
||||
@ -9,3 +13,7 @@ In addition to scanning individual images in projects, you can run global scans
|
||||
|
||||
|
||||
Scanning requires intensive resource consumption. If scanning is in progress, the **Scan Now** button is unavailable.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Scan Individual Images
|
||||
|
||||
1. Log in to the Harbor interface with an account that has at least project administrator privileges.
|
||||
@ -46,4 +50,8 @@
|
||||
|
||||
|
||||
|
||||
In addition to information about the tag, all of the vulnerabilities found in the last scan are listed. You can order or filter the list by the different columns. You can also click **Scan** in the report page to run a scan on this image tag.
|
||||
In addition to information about the tag, all of the vulnerabilities found in the last scan are listed. You can order or filter the list by the different columns. You can also click **Scan** in the report page to run a scan on this image tag.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Schedule Scans
|
||||
|
||||
You can set policies to control when vulnerability scanning should run.
|
||||
@ -14,4 +18,8 @@ You can set policies to control when vulnerability scanning should run.
|
||||
* **Daily**: Run a scan at midnight every day.
|
||||
* **Weekly**: Run a scan at midnight every Saturday.
|
||||
* **Custom**: Run a scan according to a `cron` job.
|
||||
1. Click **Save**.
|
||||
1. Click **Save**.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -1,20 +1,28 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Vulnerability Scanning
|
||||
|
||||
Harbor provides static analysis of vulnerabilities in images through the open source [Clair](https://github.com/coreos/clair) project.
|
||||
|
||||
**IMPORTANT**: Clair is an optional component. To be able to use Clair you must have enabled Clair when you installed your Harbor instance.
|
||||
|
||||
You can also connect Harbor to your own instance of Clair or to additional vulnerability scanners by using an interrogation service. You configure additional scanners in the Harbor interface, after you have installed Harbor. For the list of additional scanners that are currently supported, see the [Harbor Compatibility List](harbor_compatibility_list.md#scanner-adapters).
|
||||
You can also connect Harbor to your own instance of Clair or to additional vulnerability scanners by using an interrogation service. You configure additional scanners in the Harbor interface, after you have installed Harbor. For the list of additional scanners that are currently supported, see the [Harbor Compatibility List](../../install_config/harbor_compatibility_list.md#scanner-adapters).
|
||||
|
||||
It might be necessary to connect Harbor to other scanners for corporate compliance reasons, or because your organization already uses a particular scanner. Different scanners also use different vulnerability databases, capture different CVE sets, and apply different severity thresholds. By connecting Harbor to more than one vulnerability scanner, you broaden the scope of your protection against vulnerabilities.
|
||||
|
||||
For information about installing Harbor with Clair, see the [Installation and Configuration Guide](installation_guide.md).
|
||||
For information about installing Harbor with Clair, see the [Run the Installer Script](../../install_config/run_installer_script.md).
|
||||
|
||||
You can manually initiate scanning on a particular image, or on all images in Harbor. Additionally, you can also set a policy to automatically scan all of the images at specific intervals.
|
||||
|
||||
- [Connect Harbor to Additional Vulnerability Scanners](pluggable_scanners.md)
|
||||
- [Scan an Individual Image](scan_individual_image.md)
|
||||
- [Scan Individual Images](scan_individual_image.md)
|
||||
- [Scan All Images](scan_all_images.md)
|
||||
- [Schedule Scans](schedule_scans.md)
|
||||
- [Import Vulnerability Data to an Offline Harbor instance](import_vulnerability_data.md)
|
||||
- [Configure System-Wide CVE Whitelists](configure_system_whitelist.md)
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Build Harbor from Source Code
|
||||
|
||||
This guide provides instructions for developers to build and run Harbor from source code.
|
||||
@ -176,3 +180,8 @@ The `Makefile` contains these configurable parameters:
|
||||
$ make XXXX -e DEVFLAG=false
|
||||
|
||||
```
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,13 +1,17 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# View and test Harbor REST API via Swagger
|
||||
A Swagger file is provided for viewing and testing Harbor REST API.
|
||||
|
||||
### Viewing Harbor REST API
|
||||
## Viewing Harbor REST API
|
||||
* Open the file **swagger.yaml** under the _docs_ directory in Harbor project;
|
||||
* Paste all its content into the online Swagger Editor at http://editor.swagger.io. The descriptions of Harbor API will be shown on the right pane of the page.
|
||||
|
||||
|
||||
|
||||
### Testing Harbor REST API
|
||||
## Testing Harbor REST API
|
||||
From time to time, you may need to mannually test Harbor REST API. You can deploy the Swagger file into Harbor's service node. Suppose you install Harbor through online or offline installer, you should have a Harbor directory after you un-tar the installer, such as **~/harbor**.
|
||||
|
||||
**Caution:** When using Swagger to send REST requests to Harbor, you may alter the data of Harbor accidentally. For this reason, it is NOT recommended using Swagger against a production Harbor instance.
|
||||
@ -69,3 +73,8 @@ ui:
|
||||
* You should see a Swagger UI page with Harbor API _swagger.yaml_ file loaded in the same domain, **be aware that your REST request submitted by Swagger may change the data of Harbor**.
|
||||
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -1,4 +1,8 @@
|
||||
# Customize the look & feel of Harbor
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Customize the Harbor Look & Feel
|
||||
|
||||
The primary look & feel of Harbor supports to be customized with several simple steps. All the relevant customization in configurations are saved in the `setting.json` file under `$HARBOR_DIR/src/portal/src` folder with `json` format and will be loaded when Harbor is launched.
|
||||
|
||||
@ -35,4 +39,10 @@ Change the values of configuration if you want to override the default style to
|
||||
|
||||
## Build
|
||||
|
||||
Once the `setting.json` configurations has been updated, re-[build](#configure) your product to apply the new changes.
|
||||
Once the `setting.json` configurations has been updated, re-[build](#configure) your product to apply the new changes.
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -1,8 +1,12 @@
|
||||
## Developing for Internationalization
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Developing for Internationalization
|
||||
|
||||
*NOTE: All the files you created should use UTF-8 encoding.*
|
||||
|
||||
### Steps to localize the UI in your language
|
||||
Steps to localize the UI in your language
|
||||
|
||||
1. In the folder `src/portal/src/i18n/lang`, copy json file `en-us-lang.json` to a new file and rename it to `<language>-<locale>-lang.json` .
|
||||
|
||||
@ -56,3 +60,8 @@
|
||||
```
|
||||
|
||||
4. Next, please refer [compile guideline](compile_guide.md) to rebuild and restart Harbor.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -1,11 +0,0 @@
|
||||
# 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](compile_guide.md)
|
||||
- [Developing the Harbor Frontend](ui_contribution_get_started.md)
|
||||
- [Customize the Harbor Look & Feel ](customize_look_feel.md)
|
||||
- [Developing for Internationalization](developer_guide_i18n.md)
|
||||
- [Using Make](use_make.md)
|
||||
- [View and test Harbor REST API via Swagger](configure_swagger.md)
|
||||
- [Registry Landscape](registry_landscape.md)
|
||||
@ -1,4 +1,9 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Registry Landscape
|
||||
|
||||
The cloud native ecosystem is moving rapidly–registries and their feature sets are no exception. We've made our best effort to survey the container registry landscape and compare to our core feature set.
|
||||
|
||||
If you find something outdated or outright erroneous, please submit a PR and we'll fix it right away.
|
||||
@ -30,3 +35,8 @@ Table updated on 10/21/2019 against Harbor 1.9.
|
||||
| Vulnerability Scanning Plugin Framework | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
|
||||
| Vulnerability Whitelisting | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
|
||||
| Webhooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -1,4 +1,8 @@
|
||||
# Harbor frontend environment get started guide
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Developing the Harbor Frontend
|
||||
|
||||
If you already have a harbor backend environment, you can build a frontend development environment with the following configuration.
|
||||
|
||||
@ -92,3 +96,8 @@ If you already have a harbor backend environment, you can build a frontend devel
|
||||
|
||||
4. Then you can visit the Harbor by address: https://localhost:4200.
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -1,4 +1,10 @@
|
||||
### Variables
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
# Using Make
|
||||
|
||||
## Variables
|
||||
|
||||
Variable | Description
|
||||
-------------------|-------------
|
||||
BASEIMAGE | Container base image, default: photon
|
||||
@ -8,7 +14,8 @@ GOBUILDIMAGE | Golang image to compile harbor go source code.
|
||||
NOTARYFLAG | Whether to enable notary in harbor, default:false
|
||||
HTTPPROXY | Clarity proxy to build UI.
|
||||
|
||||
### Targets
|
||||
## Targets
|
||||
|
||||
Target | Description
|
||||
--------------------|-------------
|
||||
all | prepare env, compile binaries, build images and install images
|
||||
@ -33,9 +40,9 @@ cleanversiontag | remove specific version tag
|
||||
cleanpackage | remove online/offline install package
|
||||
version | set harbor version
|
||||
|
||||
#### EXAMPLE:
|
||||
## Examples
|
||||
|
||||
#### Build and run harbor from source code.
|
||||
### Build and run harbor from source code.
|
||||
make install GOBUILDIMAGE=golang:1.13.4 COMPILETAG=compile_golangimage NOTARYFLAG=true
|
||||
|
||||
### Package offline installer
|
||||
@ -46,3 +53,8 @@ make -e NOTARYFLAG=true start
|
||||
|
||||
### Stop harbor with notary
|
||||
make -e NOTARYFLAG=true down
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
BIN
docs/1.10/img/ha.png
Normal file
BIN
docs/1.10/img/ha.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 152 KiB |
@ -1,6 +1,6 @@
|
||||
# Harbor Documentation
|
||||
# Harbor 1.10 Documentation
|
||||
|
||||
This is the main table of contents for the Harbor documentation.
|
||||
This is the main table of contents for the Harbor 1.10.x documentation.
|
||||
|
||||
## Harbor Installation and Configuration
|
||||
|
||||
@ -14,6 +14,7 @@ This section describes how to install Harbor and perform the required initial co
|
||||
- [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)
|
||||
@ -32,30 +33,30 @@ This section describes how to use and maintain Harbor after deployment. These da
|
||||
- [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.md)
|
||||
- [Configure Project Settings](administration/configure_project_settings.md)
|
||||
- [Configure Project Quotas](administration/configure_project_quotas.md)
|
||||
- [Configuring Replication](administration/configuring_replication/configuring_replication.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/vulnerability_scanning.md)
|
||||
- [Connect Harbor to Additional Vulnerability Scanners](administration/vulnerability_scanning/pluggable_scanners.md)
|
||||
- [Scan an Individual Image](administration/vulnerability_scanning/scan_individual_image.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 Whitelists](administration/vulnerability_scanning/configure_system_whitelist.md)
|
||||
- [Garbage Collection](administration/garbage_collection.md)
|
||||
- [Upgrading Harbor](administration/upgrade/index.md)
|
||||
- [Upgrade Harbor and Migrate Data](administration/upgrade/upgrade_migrate_data.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/upgradetest.md)
|
||||
|
||||
## Working with Harbor Projects
|
||||
|
||||
This section describes how users with the developer, master, and project administrator roles manage and participate in Harbor projects.
|
||||
|
||||
- [Introduction](working_with_projects/index.md)
|
||||
- [Project Creation](working_with_projects/project_overview.md)
|
||||
- [Create a Project](working_with_projects/create_projects.md)
|
||||
- [Create Projects](working_with_projects/create_projects.md)
|
||||
- [Assign Users to a Project](working_with_projects/add_users.md)
|
||||
- [Project Configuration](working_with_projects/project_configuration.md)
|
||||
- [Access and Search Project Logs](working_with_projects/access_project_logs.md)
|
||||
@ -75,7 +76,6 @@ This section describes how users with the developer, master, and project adminis
|
||||
|
||||
This section describes how developers can build from Harbor source code, customize their deployments, and contribute to the open-source Harbor project.
|
||||
|
||||
- [Introduction](build_customize_contribute/index.md)
|
||||
- [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)
|
||||
|
||||
@ -115,8 +115,7 @@ After generating the `ca.crt`, `yourdomain.com.crt`, and `yourdomain.com.key` fi
|
||||
|
||||
`systemctl restart docker`
|
||||
|
||||
You might also need to trust the certificate at the OS level. See [Troubleshooting Harbor Installation
|
||||
](troubleshoot_installation.md#https) for more information.
|
||||
You might also need to trust the certificate at the OS level. See [Troubleshooting Harbor Installation](troubleshoot_installation.md#https) for more information.
|
||||
|
||||
The following example illustrates a configuration that uses custom certificates.
|
||||
|
||||
@ -179,8 +178,7 @@ After setting up HTTPS for Harbor, you can verify the HTTPS connection by perfor
|
||||
## What to Do Next ##
|
||||
|
||||
- If the verification succeeds, see [Harbor Administration](../administration/index.md) for information about using Harbor.
|
||||
- If installation fails, see [Troubleshooting Harbor Installation
|
||||
](troubleshoot_installation.md).
|
||||
- If installation fails, see [Troubleshooting Harbor Installation](troubleshoot_installation.md).
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -1,67 +1,80 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Configure Harbor User Settings at the Command Line
|
||||
|
||||
After release 1.8.0, all user settings are separated from system settings, it can not be configured in config file anymore. Users need to configure it with admin privileges in web console or via HTTP request.
|
||||
From release 1.8.0 onwards, user settings are configured separately from the system settings. You do not configure user settings in the `harbor.yml` file, but rather in the Harbor interface or via HTTP requests.
|
||||
|
||||
## Example Configuration Commands:
|
||||
|
||||
**Add a new user in the local database:**
|
||||
|
||||
`curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki <Harbor Server URL>/api/configurations -d'{"<item_name>":"<item_value>"}'`
|
||||
|
||||
Get current configurations
|
||||
**Get the current configuration:**
|
||||
|
||||
`curl -u "<username>:<password>" -H "Content-Type: application/json" -ki <Harbor Server URL>/api/configurations`
|
||||
|
||||
## Sample config commands:
|
||||
**Update Harbor to use LDAP authentication:**
|
||||
|
||||
1. Update Harbor to use LDAP auth
|
||||
Command
|
||||
|
||||
Command
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"auth_mode":"ldap_auth"}'
|
||||
```
|
||||
Output
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:22:02 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=a5803a1265e2b095cf65ce1d8bbd79b1; Path=/; HttpOnly
|
||||
```
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"auth_mode":"ldap_auth"}'
|
||||
```
|
||||
|
||||
1. Restrict project creation to admin only
|
||||
Output
|
||||
|
||||
Command
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"project_creation_restriction":"adminonly"}'
|
||||
```
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:22:02 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=a5803a1265e2b095cf65ce1d8bbd79b1; Path=/; HttpOnly
|
||||
```
|
||||
|
||||
Output
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:24:32 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=b7925eaf7af53bdefb13bdcae201a14a; Path=/; HttpOnly
|
||||
```
|
||||
**Restrict project creation to Harbor administrators:**
|
||||
|
||||
1. Update the token expiration time
|
||||
Command
|
||||
|
||||
Command
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"token_expiration":"300"}'
|
||||
```
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"project_creation_restriction":"adminonly"}'
|
||||
```
|
||||
|
||||
Output
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:23:38 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=cc1bc93ffa2675253fc62b4bf3d9de0e; Path=/; HttpOnly
|
||||
```
|
||||
Output
|
||||
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:24:32 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=b7925eaf7af53bdefb13bdcae201a14a; Path=/; HttpOnly
|
||||
```
|
||||
|
||||
**Update the token expiration time:**
|
||||
|
||||
Command
|
||||
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"token_expiration":"300"}'
|
||||
```
|
||||
|
||||
Output
|
||||
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:23:38 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=cc1bc93ffa2675253fc62b4bf3d9de0e; Path=/; HttpOnly
|
||||
```
|
||||
|
||||
## Harbor user settings
|
||||
|
||||
@ -99,14 +112,19 @@ uaa_client_id | UAA client ID | string | required(uaa_auth)
|
||||
uaa_client_secret | UAA certificate | string | required(uaa_auth)
|
||||
uaa_endpoint | UAA endpoint | string | required(uaa_auth)
|
||||
uaa_verify_cert | UAA verify cert, true or false | boolean | optional | true
|
||||
oidc_name | name for OIDC authentication | string | required(oidc_auth)
|
||||
oidc_endpoint | endpoint for OIDC auth | string | required(oidc_auth)
|
||||
oidc_client_id | client id for OIDC auth | string | required(oidc_auth)
|
||||
oidc_client_secret | client secret for OIDC auth |string | required(oidc_auth)
|
||||
oidc_scope | scope for OIDC auth | string| required(oidc_auth)
|
||||
oidc_verify_cert | verify cert for OIDC auth, true or false | boolean | optional| true
|
||||
oidc_name | Name for OIDC authentication | string | required(oidc_auth)
|
||||
oidc_endpoint | Endpoint for OIDC auth | string | required(oidc_auth)
|
||||
oidc_client_id | Client id for OIDC auth | string | required(oidc_auth)
|
||||
oidc_client_secret | Client secret for OIDC auth |string | required(oidc_auth)
|
||||
oidc_scope | Ccope for OIDC auth | string| required(oidc_auth)
|
||||
oidc_verify_cert | Verify certificate for OIDC auth, true or false | boolean | optional| true
|
||||
robot_token_duration | Robot token expiration time in minutes | number | optional | 43200 (30days)
|
||||
|
||||
|
||||
|
||||
**Note:** Both boolean and number can be enclosed with double quote in the request json, for example: `123`, `"123"`, `"true"` or `true` is OK.
|
||||
**Note:** Both booleans and numbers can be enclosed with double quote in the request json, for example: `123`, `"123"`, `"true"` or `true` is OK.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -6,59 +6,62 @@
|
||||
|
||||
By default, Harbor uses its own private key and certificate to authenticate with Docker clients. This topic describes how to optionally customize your configuration to use your own key and certificate.
|
||||
|
||||
Harbor requires Docker client to access the Harbor registry with a token. The procedure to generate a token is like [Docker Registry v2 authentication](https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md). Firstly, you should make a request to the token service for a token. The token is signed by the private key. After that, you make a new request with the token to the Harbor registry, Harbor registry will verify the token with the public key in the rootcert bundle. Then Harbor registry will authorize the Docker client to push/pull images.
|
||||
Harbor requires the Docker client to access the Harbor registry with a token. The procedure to generate a token is like [Docker Registry v2 authentication](https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md). Firstly, you make a request to the token service for a token. The token is signed by the private key. After that, you make a new request with the token to the Harbor registry, Harbor registry verifies the token with the public key in the root cert bundle. Then Harbor registry authorizes the Docker client to push and pull images.
|
||||
|
||||
1. If you already have a certificate, go to step 3.
|
||||
1. If not, you can generate a root certificate using openSSL with following commands:
|
||||
- If you do not already have a certificate, follow the instructions in [Generate a Root Certificate](#gen-cert) to generate a root certificate by using openSSL.
|
||||
- If you already have a certificate, go to [Provide the Certificate to Harbor](#provide-cert).
|
||||
|
||||
<a id="gen-cert"></a>
|
||||
## Generate a Root Certificate
|
||||
|
||||
**1)Generate a private key:**
|
||||
1. Generate a private key.
|
||||
|
||||
```sh
|
||||
$ openssl genrsa -out private_key.pem 4096
|
||||
```
|
||||
```sh
|
||||
$ openssl genrsa -out private_key.pem 4096
|
||||
```
|
||||
|
||||
**2)Generate a certificate:**
|
||||
```sh
|
||||
$ openssl req -new -x509 -key private_key.pem -out root.crt -days 3650
|
||||
```
|
||||
You are about to be asked to enter information that will be incorporated into your certificate request.
|
||||
What you are about to enter is what is called a Distinguished Name or a DN.
|
||||
There are quite a few fields but you can leave some blank
|
||||
For some fields there will be a default value,
|
||||
If you enter '.', the field will be left blank. Following are what you're asked to enter.
|
||||
1. Generate a certificate.
|
||||
|
||||
Country Name (2 letter code) [AU]:
|
||||
```sh
|
||||
$ openssl req -new -x509 -key private_key.pem -out root.crt -days 3650
|
||||
```
|
||||
|
||||
State or Province Name (full name) [Some-State]:
|
||||
1. Enter information to include in your certificate request.
|
||||
|
||||
Locality Name (eg, city) []:
|
||||
What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some of them blank. For some fields there is a default value. If you enter `.`, the field is left blank.
|
||||
|
||||
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
|
||||
- Country Name (2 letter code) [AU]:
|
||||
- State or Province Name (full name) [Some-State]:
|
||||
- Locality Name (eg, city) []:
|
||||
- Organization Name (eg, company) [Internet Widgits Pty Ltd]:
|
||||
- Organizational Unit Name (eg, section) []:
|
||||
- Common Name (eg, server FQDN or YOUR name) []:
|
||||
- Email Address []:
|
||||
|
||||
Organizational Unit Name (eg, section) []:
|
||||
After you run these commands, the files `private_key.pem` and `root.crt` are created in the current directory.
|
||||
|
||||
Common Name (eg, server FQDN or YOUR name) []:
|
||||
<a id="provide-cert"></a>
|
||||
## Provide the Certificate to Harbor
|
||||
|
||||
Email Address []:
|
||||
See [Run the Installer Script](run_installer_script.md) or [Reconfigure Harbor and Manage the Harbor Lifecycle](reconfigure_manage_lifecycle.md) to install or reconfigure Harbor. After you run `./install` or `./prepare`, Harbor generates several configuration files. You need to replace the original private key and certificate with your own key and certificate.
|
||||
|
||||
After you execute these two commands, you will see private_key.pem and root.crt in the **current directory**, just type "ls", you'll see them.
|
||||
1. Replace the default key and certificate.
|
||||
|
||||
3.Refer to [Installation Guide](https://github.com/goharbor/harbor/blob/master/docs/installation_guide.md) to install Harbor, After you execute ./prepare, Harbor generates several config files. We need to replace the original private key and certificate with your own key and certificate.
|
||||
Assuming that the key and certificate are in `/root/cert`, run the following commands:
|
||||
|
||||
4.Replace the default key and certificate. Assume that you key and certificate are in the directory /root/cert, following are what you should do:
|
||||
```
|
||||
$ cd config/ui
|
||||
$ cp /root/cert/private_key.pem private_key.pem
|
||||
$ cp /root/cert/root.crt ../registry/root.crt
|
||||
```
|
||||
|
||||
```
|
||||
$ cd config/ui
|
||||
$ cp /root/cert/private_key.pem private_key.pem
|
||||
$ cp /root/cert/root.crt ../registry/root.crt
|
||||
```
|
||||
1. Go back to the `make` directory, and start Harbor by using following command:
|
||||
|
||||
5.After these, go back to the make directory, you can start Harbor using following command:
|
||||
```
|
||||
$ docker-compose up -d
|
||||
```
|
||||
```
|
||||
$ docker-compose up -d
|
||||
```
|
||||
|
||||
6.Then you can push/pull images to see if your own certificate works. Please refer [User Guide](https://github.com/goharbor/harbor/blob/master/docs/user_guide.md) for more info.
|
||||
1. Push and pull images to and from Harbor to check that your own certificate works.
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@ If you encounter any problems while using the demo server, open an [issue on Git
|
||||
1. Explore the default project, `library`.
|
||||
1. Click **New Project** to create your own project.
|
||||
|
||||
For information about how to create a project, see [Create a Project](../../working_with_projects/create_projects.md).
|
||||
For information about how to create a project, see [Create a Project](../working_with_projects/create_projects.md).
|
||||
1. Open a Docker client and log in to Harbor with the credentials that you created above.
|
||||
|
||||
```
|
||||
|
||||
85
docs/1.10/install_config/harbor_ha_helm.md
Normal file
85
docs/1.10/install_config/harbor_ha_helm.md
Normal file
@ -0,0 +1,85 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Deploying Harbor with High Availability via Helm
|
||||
|
||||
## Goal
|
||||
|
||||
Deploy Harbor on K8S via helm to make it highly available, that is, if one of node that has Harbor's container running becomes un accessible. Users does not experience interrupt of service of Harbor.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Kubernetes cluster 1.10+
|
||||
- Helm 2.8.0+
|
||||
- High available ingress controller (Harbor does not manage the external endpoint)
|
||||
- High available PostgreSQL database (Harbor does not handle the deployment of HA of database)
|
||||
- High available Redis (Harbor does not handle the deployment of HA of Redis)
|
||||
- PVC that can be shared across nodes or external object storage
|
||||
|
||||
## Architecture
|
||||
|
||||
Most of Harbor's components are stateless now. So we can simply increase the replica of the pods to make sure the components are distributed to multiple worker nodes, and leverage the "Service" mechanism of K8S to ensure the connectivity across pods.
|
||||
|
||||
As for storage layer, it is expected that the user provide high available PostgreSQL, Redis cluster for application data and PVCs or object storage for storing images and charts.
|
||||
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
### Download Chart
|
||||
|
||||
Download Harbor helm chart:
|
||||
|
||||
```bash
|
||||
helm repo add harbor https://helm.goharbor.io
|
||||
helm fetch harbor/harbor --untar
|
||||
```
|
||||
|
||||
### Configuration
|
||||
|
||||
Configure the followings items in `values.yaml`, you can also set them as parameters via `--set` flag during running `helm install`:
|
||||
|
||||
- **Ingress rule**
|
||||
Configure the `expose.ingress.hosts.core` and `expose.ingress.hosts.notary`.
|
||||
- **External URL**
|
||||
Configure the `externalURL`.
|
||||
- **External PostgreSQL**
|
||||
Set the `database.type` to `external` and fill the information in `database.external` section.
|
||||
|
||||
Four empty databases should be created manually for `Harbor core`, `Clair`, `Notary server` and `Notary signer` and configure them in the section. Harbor will create tables automatically when starting up.
|
||||
- **External Redis**
|
||||
Set the `redis.type` to `external` and fill the information in `redis.external` section.
|
||||
|
||||
As the Redis client used by Harbor's upstream projects doesn't support `Sentinel`, Harbor can only work with a single entry point Redis. You can refer to this [guide](https://community.pivotal.io/s/article/How-to-setup-HAProxy-and-Redis-Sentinel-for-automatic-failover-between-Redis-Master-and-Slave-servers) to setup a HAProxy before the Redis to expose a single entry point.
|
||||
- **Storage**
|
||||
By default, a default `StorageClass` is needed in the K8S cluster to provision volumes to store images, charts and job logs.
|
||||
|
||||
If you want to specify the `StorageClass`, set `persistence.persistentVolumeClaim.registry.storageClass`, `persistence.persistentVolumeClaim.chartmuseum.storageClass` and `persistence.persistentVolumeClaim.jobservice.storageClass`.
|
||||
|
||||
If you use `StorageClass`, for both default or specified one, set `persistence.persistentVolumeClaim.registry.accessMode`, `persistence.persistentVolumeClaim.chartmuseum.accessMode` and `persistence.persistentVolumeClaim.jobservice.accessMode` as `ReadWriteMany`, and make sure that the persistent volumes must can be shared cross different nodes.
|
||||
|
||||
You can also use the existing PVCs to store data, set `persistence.persistentVolumeClaim.registry.existingClaim`, `persistence.persistentVolumeClaim.chartmuseum.existingClaim` and `persistence.persistentVolumeClaim.jobservice.existingClaim`.
|
||||
|
||||
If you have no PVCs that can be shared across nodes, you can use external object storage to store images and charts and store the job logs in database. Set the `persistence.imageChartStorage.type` to the value you want to use and fill the corresponding section and set `jobservice.jobLogger` to `database`.
|
||||
|
||||
- **Replica**
|
||||
Set `portal.replicas`, `core.replicas`, `jobservice.replicas`, `registry.replicas`, `chartmuseum.replicas`, `clair.replicas`, `notary.server.replicas` and `notary.signer.replicas` to `n`(`n`>=2).
|
||||
|
||||
### Installation
|
||||
|
||||
Install the Harbor helm chart with a release name `my-release`:
|
||||
|
||||
helm 2:
|
||||
```bash
|
||||
helm install --name my-release .
|
||||
```
|
||||
helm 3:
|
||||
```
|
||||
helm install my-release .
|
||||
```
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -6,9 +6,7 @@
|
||||
|
||||
This section describes how to perform a new installation of Harbor.
|
||||
|
||||
If you are upgrading from a previous version of Harbor, you might need to update the configuration file and migrate your data to fit the database schema of the later version. For information about upgrading, see [Upgrading Harbor](../../administration/upgrade/index.md).
|
||||
|
||||
You can also use Helm to install Harbor on a Kubernetes cluster, to make it highly available. For information about installing Harbor with Helm on a Kubernetes cluster, see the [Harbor High Availability Guide](https://github.com/goharbor/harbor-helm/blob/master/docs/High%20Availability.md) in the https://github.com/goharbor/harbor-helm repository.
|
||||
If you are upgrading from a previous version of Harbor, you might need to update the configuration file and migrate your data to fit the database schema of the later version. For information about upgrading, see [Upgrading Harbor](../../administration/upgrade/upgrade_migrate_data.md).
|
||||
|
||||
Before you install Harbor, you can test its functionality on a demo server that the Harbor team has made available. For information, see [Test Harbor with the Demo Server](demo_server.md).
|
||||
|
||||
@ -24,8 +22,9 @@ The standard Harbor installation process involves the following stages:
|
||||
1. [Configure the Harbor YML File](configure_yml_file.md)
|
||||
1. [Run the Installer Script](run_installer_script.md)
|
||||
|
||||
If installation fails, see [Troubleshooting Harbor Installation
|
||||
](troubleshoot_installation.md).
|
||||
You can also use Helm to install Harbor on a Kubernetes cluster, to make it highly available. For information about installing Harbor with Helm on a Kubernetes cluster, see the [Deploying Harbor with High Availability via Helm](harbor_ha_helm.md).
|
||||
|
||||
If installation fails, see [Troubleshooting Harbor Installation](troubleshoot_installation.md).
|
||||
|
||||
## Post-Installation Configuration
|
||||
|
||||
@ -52,4 +51,4 @@ The table below lists the components that are deployed when you deploy Harbor.
|
||||
|Swagger-ui|3.22.1|
|
||||
|
||||
----------
|
||||
[Back to table of contents](../../index.md)
|
||||
[Back to table of contents](../index.md)
|
||||
@ -106,8 +106,7 @@ After you update `daemon.json`, you must restart both Docker Engine and Harbor.
|
||||
|
||||
- If the installation succeeds, see [Harbor Administration](../administration/index.md) for information about using Harbor.
|
||||
- If you deployed Harbor with HTTP and you want to secure the connections to Harbor, see [Configure HTTPS Access to Harbor](configure_https.md).
|
||||
- If installation fails, see [Troubleshooting Harbor Installation
|
||||
](troubleshoot_installation.md).
|
||||
- If installation fails, see [Troubleshooting Harbor Installation](troubleshoot_installation.md).
|
||||
|
||||
----------
|
||||
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Access and Search Project Logs
|
||||
|
||||
Harbor keeps a log of all of the operations that users perform in a project. You can apply filters to help you to search the logs.
|
||||
@ -25,7 +29,6 @@ Log in to Harbor with a Harbor administrator, project administrator, master, dev
|
||||
|
||||
|
||||
|
||||
## What to Do Next
|
||||
|
||||
TBD
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Assign Users to a Project
|
||||
|
||||
You can add individual users to an existing project and assign a role to them. You can add an LDAP/AD or OIDC user to the project members if you use LDAP/AD or OIDC authentication, or a user that you have already created if you use database authentication. If you use LDAP/AD or OIDC authentication, you can add groups to projects and assign a role to the group.
|
||||
@ -51,6 +55,6 @@ To be able to add OIDC groups to projects, your OIDC provider and Harbor instanc
|
||||
|
||||
**NOTE**: Unlike with LDAP groups, Harbor cannot check whether OIDC groups exist when you add them to a project. If you mistype the group name, or if the group does not exist in your OIDC provider, Harbor still creates the group.
|
||||
|
||||
## What to Do Next
|
||||
----------
|
||||
|
||||
TBD
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,8 +1,12 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Configure a Per-Project CVE Whitelist
|
||||
|
||||
When you run vulnerability scans, images that are subject to Common Vulnerabilities and Exposures (CVE) are identified. According to the severity of the CVE and your security settings, these images might not be permitted to run. You can create whitelists of CVEs to ignore during vulnerability scanning.
|
||||
|
||||
Harbor administrators can set a system-wide CVE whitelist. For information about site-wide CVE whitelists, see [Configure System-Wide CVE Whitelists](../administration/vulnerability_scanning/configire_system_whitelist.md). By default, the system whitelist is applied to all projects. You can configure different CVE whitelists for individual projects, that override the system whitelist.
|
||||
Harbor administrators can set a system-wide CVE whitelist. For information about site-wide CVE whitelists, see [Configure System-Wide CVE Whitelists](../administration/vulnerability_scanning/configure_system_whitelist.md). By default, the system whitelist is applied to all projects. You can configure different CVE whitelists for individual projects, that override the system whitelist.
|
||||
|
||||
1. Go to **Projects**, select a project, and select **Configuration**.
|
||||
1. Under **CVE whitelist**, select **Project whitelist**.
|
||||
@ -20,4 +24,8 @@ After you have created a project whitelist, you can remove CVE IDs from the list
|
||||
|
||||
If CVEs are added to the system whitelist after you have created a project whitelist, click **Copy From System** to add the new entries from the system whitelist to the project whitelist.
|
||||
|
||||
**NOTE**: If CVEs are deleted from the system whitelist after you have created a project whitelist, and if you added the system whitelist to the project whitelist, you must manually remove the deleted CVEs from the project whitelist. If you click **Copy From System** after CVEs have been deleted from the system whitelist, the deleted CVEs are not automatically removed from the project whitelist.
|
||||
**NOTE**: If CVEs are deleted from the system whitelist after you have created a project whitelist, and if you added the system whitelist to the project whitelist, you must manually remove the deleted CVEs from the project whitelist. If you click **Copy From System** after CVEs have been deleted from the system whitelist, the deleted CVEs are not automatically removed from the project whitelist.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Configure Webhook Notifications
|
||||
|
||||
If you are a project administrator, you can configure a connection from a project in Harbor to a webhook endpoint. If you configure webhooks, Harbor notifies the webhook endpoint of certain events that occur in the project. Webhooks allow you to integrate Harbor with other tools to streamline continuous integration and development processes.
|
||||
@ -87,4 +91,8 @@ As a Harbor system administrator, you can enable and disable webhook notificatio
|
||||
1. Go to **Configuration** > **System Settings**.
|
||||
1. Scroll down and check or uncheck the **Webhooks enabled** check box.
|
||||
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Managing Labels
|
||||
|
||||
Harbor provides two kinds of labels to isolate different kinds of resources:
|
||||
@ -23,4 +27,8 @@ Users who have Harbor system administrator, project administrator or project dev
|
||||
## Filtering Images by Label
|
||||
The images can be filtered by labels:
|
||||
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
@ -1,6 +1,17 @@
|
||||
# Create a Project
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
In Harbor, you create different projects to which you assign users so that they can push and pull image repositories. You also configure project-specific settings. When you first deploy Harbor, a default public project named `library` is created.
|
||||
----------
|
||||
|
||||
# Create Projects
|
||||
|
||||
A project in Harbor contains all repositories of an application. Images cannot be pushed to Harbor before a project is created. Role-Based Access Control (RBAC) is applied to projects, so that only users with the appropriate roles can perform certain operations.
|
||||
|
||||
There are two types of project in Harbor:
|
||||
|
||||
* **Public**: Any user can pull images from this project. This is a convenient way for you to share repositories with others.
|
||||
* **Private**: Only users who are members of the project can pull images
|
||||
|
||||
You create different projects to which you assign users so that they can push and pull image repositories. You also configure project-specific settings. When you first deploy Harbor, a default public project named `library` is created.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@ -30,7 +41,7 @@ Project properties can be changed by clicking "Configuration".
|
||||
|
||||
* To make all repositories under the project accessible to everyone, select the `Public` checkbox.
|
||||
|
||||
* To prevent un-signed images under the project from being pulled, select the `Enable content trust` checkbox.
|
||||
* To prevent un-signed images under the project from being pulled, select the `Enable content trust` checkbox. For more information about content trust, see [Implementing Content Trust](implementing_content_trust.md).
|
||||
|
||||
|
||||
|
||||
@ -42,4 +53,8 @@ Entering a keyword in the search field at the top lists all matching projects an
|
||||
|
||||
## What to Do Next
|
||||
|
||||
[Assign Users to a Project](add_users.md)
|
||||
[Assign Users to a Project](add_users.md)
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Create Robot Accounts
|
||||
|
||||
You can create robot accounts to run automated operations. Robot accounts have the following limitations:
|
||||
@ -50,4 +54,8 @@ To use a robot account in an automated process, for example a script, use `docke
|
||||
docker login <i>harbor_address</i>
|
||||
Username: robot$<i>account_name</i>
|
||||
Password: <i>robot_account_token</i>
|
||||
</pre>
|
||||
</pre>
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Tag Immutability Rules
|
||||
|
||||
By default, users can repeatedly push an image with the same tag to repositories in Harbor. This causes the previous image to effectively be overwritten with each push, in that the tag now points to a different image and the image that previously used the tag now becomes tagless. This is due to the Docker implementation, that does not enforce the mapping between an image tag and the image digest. This can be undesirable in certain cases, because the tag can no longer be trusted to identify the image version. The sha256 digest remains reliable and always points to the same build, but it is not rendered in a human-readable format.
|
||||
@ -50,4 +54,8 @@ To make all tags for all repositories in the project immutable, set the followin
|
||||
To allow the tags `rc`, `test`, and `nightly` to be overwritten but make all other tags immutable, set the following options:
|
||||
|
||||
- Set **For the respositories** to **matching** and enter `**`.
|
||||
- Set **Tags** to **excluding** and enter `rc,test,nightly`.
|
||||
- Set **Tags** to **excluding** and enter `rc,test,nightly`.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Create Tag Retention Rules
|
||||
|
||||
A repository can rapidly accumulate a large number of image tags, many of which might not be required after a given time or once they have been superseded by a subsequent image build. These excess tags can obviously consume large quantities of storage capacity. As a Harbor system administrator, you can define rules that govern how many tags of a given repository to retain, or for how long to retain certain tags.
|
||||
@ -93,7 +97,7 @@ In this example, the rules are applied to the following 7 tags:
|
||||
|
||||
## How Tag Retention Rules Interact with Project Quotas
|
||||
|
||||
The Harbor system administrator can set a maximum on the number of tags that a project can contain and the amount of storage that it can consume. For information about project quotas, see [Set Project Quotas](#set-project-quotas).
|
||||
The Harbor system administrator can set a maximum on the number of tags that a project can contain and the amount of storage that it can consume. For information about project quotas, see [Configure Project Quotas](../administration/configure_project_quotas.md).
|
||||
|
||||
If you set a quota on a project, this quota cannot be exceeded. The quota is applied to a project even if you set a retention rule that would exceed it. In other words, you cannot use retention rules to bypass quotas.
|
||||
|
||||
@ -154,4 +158,8 @@ If you set a quota on a project, this quota cannot be exceeded. The quota is app
|
||||
|
||||
To modify an existing rule, use the **Action** drop-down menu next to a rule to disable, edit, or delete that rule.
|
||||
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Implementing Content Trust
|
||||
|
||||
**NOTE: Notary is an optional component, please make sure you have already installed it in your Harbor instance before you go through this section.**
|
||||
@ -14,4 +18,8 @@ If you are using a self-signed cert, make sure to copy the CA cert into ```/etc/
|
||||
**Note: Replace "10.117.169.182" with the IP address or domain name of your Harbor node. In order to use content trust, HTTPS must be enabled in Harbor.**
|
||||
|
||||
When an image is signed, it has a tick shown in UI; otherwise, a cross sign(X) is displayed instead.
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -2,6 +2,10 @@
|
||||
|
||||
This section describes how users with the developer, master, and project administrator roles manage and participate in Harbor projects. The Harbor administrator can also perform all of these tasks.
|
||||
|
||||
- [Project Creation](project_overview.md)
|
||||
- [Create Projects](create_projects.md)
|
||||
- [Project Configuration](project_configuration.md)
|
||||
- [Working with Images, Tags, and Helm Charts](working_with_images.md)
|
||||
- [Working with Images, Tags, and Helm Charts](working_with_images.md)
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Managing Helm Charts
|
||||
[Helm](https://helm.sh) is a package manager for [Kubernetes](https://kubernetes.io). Helm uses a packaging format called [charts](https://docs.helm.sh/developing_charts). Since version 1.6.0 Harbor is now a composite cloud-native registry which supports both container image management and Helm charts management. Access to Helm charts in Harbor is controlled by [role-based access controls (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control) and is restricted by projects.
|
||||
|
||||
@ -119,4 +123,8 @@ Everything is ready, install the chart to your kubernetes:
|
||||
helm install --ca-file=ca.crt --username=admin --password=Passw0rd --version 0.1.10 repo248/chart_repo/hello-helm
|
||||
```
|
||||
|
||||
For other more helm commands like how to sign a chart, please refer to the [helm doc](https://docs.helm.sh/helm/#helm).
|
||||
For other more helm commands like how to sign a chart, please refer to the [helm doc](https://docs.helm.sh/helm/#helm).
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,19 +1,23 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Project Configuration
|
||||
|
||||
Project properties can be changed by clicking "Configuration".
|
||||
After the initial creation of a project, you can configure or reconfigure its properties in the **Configuration** tab for that project.
|
||||
|
||||
* To make all repositories under the project accessible to everyone, select the `Public` checkbox.
|
||||
|
||||
* To prevent un-signed images under the project from being pulled, select the `Enable content trust` checkbox.
|
||||
|
||||
* To activate an immediate vulnerability scan on new images that are pushed to the project, select the `Automatically scan images on push` checkbox.
|
||||
1. Log in to the Harbor interface with an account that has at least project administrator privileges.
|
||||
1. Go to **Projects** and select a project.
|
||||
1. Select the **Configuration** tab.
|
||||
1. To make all repositories under the project accessible to everyone, select the `Public` checkbox, or deselect this checkbox to make the project private.
|
||||
1. To prevent un-signed images under the project from being pulled, select the `Enable content trust` checkbox.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Searching projects and repositories
|
||||
Entering a keyword in the search field at the top lists all matching projects and repositories. The search result includes both public and private repositories you have access to.
|
||||
|
||||
Enter a keyword in the search field at the top to list all matching projects and repositories. The search result includes both public and private repositories you have access to.
|
||||
|
||||
|
||||
|
||||
@ -43,4 +47,8 @@ Build history makes it easy to see the contents of a container image, find the c
|
||||
|
||||
In Harbor portal, enter your project, select the repository, click on the link of tag name you'd like to see its build history, the detail page will be opened. Then switch to `Build History` tab, you can see the build history information.
|
||||
|
||||
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,8 +0,0 @@
|
||||
# Project Creation
|
||||
|
||||
A project in Harbor contains all repositories of an application. Images cannot be pushed to Harbor before a project is created. Role-Based Access Control (RBAC) is applied to projects, so that only users with the appropriate roles can perform certain operations.
|
||||
|
||||
There are two types of project in Harbor:
|
||||
|
||||
* **Public**: Any user can pull images from this project. This is a convenient way for you to share repositories with others.
|
||||
* **Private**: Only users who are members of the project can pull images
|
||||
@ -4,118 +4,114 @@
|
||||
|
||||
# Pulling and Pushing Images in the Docker Client
|
||||
|
||||
**NOTE**: Harbor only supports the Registry V2 API. You must use Docker client 1.6.0 or higher.
|
||||
|
||||
Harbor optionally supports HTTP connections, however the Docker client always attempts to connect to registries by first using HTTPS. If Harbor is configured for HTTP, you must configure your Docker client so that it can connect to insecure registries. In your Docker client is not configured for insecure registries, you will see the following error when you attempt to pull or push images to Harbor:
|
||||
|
||||
<pre>
|
||||
Error response from daemon: Get https://<i>myregistrydomain.com</i>/v1/users/: dial tcp <i>myregistrydomain.com</i>:443 getsockopt: connection refused.
|
||||
</pre>
|
||||
|
||||
For information about how to add insecure registries to your Docker client, see [Connecting to Harbor via HTTP](installation_guide.md#connect_http) in the *Harbor Installation and Configuration Guide*.
|
||||
For information about how to add insecure registries to your Docker client, see [Connecting to Harbor via HTTP](../install_config/run_installer_script.md#connect_http).
|
||||
|
||||
You also see this error if Harbor uses HTTPS with an unknown CA certificate. In this case, obtain the registry's CA certificate, and copy it to <code>/etc/docker/certs.d/<i>myregistrydomain.com</i>/ca.crt</code>.
|
||||
|
||||
**NOTE**: Harbor only supports the Registry V2 API. You must use Docker client 1.6.0 or higher when pushing and pulling images.
|
||||
|
||||
## Pulling Images
|
||||
If the project that the image belongs to is private, you should sign in first:
|
||||
|
||||
If the project that the image belongs to is private, you must sign in first:
|
||||
|
||||
```
|
||||
sh
|
||||
$ docker login 10.117.169.182
|
||||
$ docker login <harbor_address>
|
||||
```
|
||||
|
||||
You can now pull the image:
|
||||
You can now pull an image:
|
||||
|
||||
```
|
||||
sh
|
||||
$ docker pull 10.117.169.182/library/ubuntu:14.04
|
||||
$ docker pull <harbor_address>/library/ubuntu:14.04
|
||||
```
|
||||
|
||||
**Note**: Replace "10.117.169.182" with the IP address or domain name of your Harbor node. You cannot pull an unsigned image if you enabled content trust.
|
||||
**NOTE**: You cannot pull an unsigned image if you have enabled content trust.
|
||||
|
||||
## Pushing Images
|
||||
Before pushing an image, you must create a corresponding project on Harbor web UI.
|
||||
|
||||
Before you can push an image to Harbor, you must create a corresponding project in the Harbor interface. For information about how to create a project, see [Create Projects](create_projects.md).
|
||||
|
||||
First, log in from Docker client:
|
||||
|
||||
```
|
||||
sh
|
||||
$ docker login 10.117.169.182
|
||||
$ docker login <harbor_address>
|
||||
```
|
||||
|
||||
Tag the image:
|
||||
|
||||
```
|
||||
sh
|
||||
$ docker tag ubuntu:14.04 10.117.169.182/demo/ubuntu:14.04
|
||||
$ docker tag ubuntu:14.04 <harbor_address>/demo/ubuntu:14.04
|
||||
```
|
||||
|
||||
Push the image:
|
||||
|
||||
```
|
||||
sh
|
||||
$ docker push 10.117.169.182/demo/ubuntu:14.04
|
||||
$ docker push <harbor_address>/demo/ubuntu:14.04
|
||||
```
|
||||
|
||||
**Note: Replace "10.117.169.182" with the IP address or domain name of your Harbor node.**
|
||||
|
||||
## Add Descriptions to Repositories
|
||||
|
||||
After pushing an image, an Information can be added by project admin to describe this repository.
|
||||
After pushing an image, the project administrator can add information to describe the repository.
|
||||
|
||||
Go into the repository and select the "Info" tab, and click the "EDIT" button. An textarea will appear and enter description here. Click "SAVE" button to save this information.
|
||||
Go into the repository and select the **Info** tab, and click the **Edit** button. Enter a description and click **Save** to save the description.
|
||||
|
||||
|
||||
|
||||
## Download the Harbor Certificate
|
||||
|
||||
Users can click the "registry certificate" link to download the registry certificate.
|
||||
Users can click the **Registry Certificate** button to download the registry certificate.
|
||||
|
||||
|
||||
|
||||
## Deleting Repositories
|
||||
|
||||
Repository deletion runs in two steps.
|
||||
Deleting repositories involves two steps.
|
||||
|
||||
First, delete a repository in Harbor's UI. This is soft deletion. You can delete the entire repository or just a tag of it. After the soft deletion,
|
||||
the repository is no longer managed in Harbor, however, the files of the repository still remain in Harbor's storage.
|
||||
First, you delete a repository in the Harbor interface. This is soft deletion. You can delete the entire repository or just one of its tags. After the soft deletion, the repository is no longer managed by Harbor, however, the repository files remain in the Harbor storage.
|
||||
|
||||
|
||||
|
||||
|
||||
**CAUTION: If both tag A and tag B refer to the same image, after deleting tag A, B will also get deleted. if you enabled content trust, you need to use notary command line tool to delete the tag's signature before you delete an image.**
|
||||
|
||||
Next, delete the actual files of the repository using the [garbage collection](#online-garbage-collection) in Harbor's UI.
|
||||
|
||||
|
||||
Next, delete the repository files by running [garbage collection](../administration/garbage_collection.md) in the Harbor interface.
|
||||
|
||||
## Pulling Images from Harbor in Kubernetes
|
||||
Kubernetes users can easily deploy pods with images stored in Harbor. The settings are similar to that of another private registry. There are two major issues:
|
||||
Kubernetes users can easily deploy pods with images stored in Harbor. The settings are similar to those of any other private registry. There are two issues to be aware of:
|
||||
|
||||
1. When your Harbor instance is hosting http and the certificate is self signed. You need to modify daemon.json on each work node of your cluster, for details please refer to: https://docs.docker.com/registry/insecure/#deploy-a-plain-http-registry
|
||||
2. If your pod references an image under private project, you need to create a secret with the credentials of user who has permission to pull image from this project, for details refer to: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
|
||||
1. When your Harbor instance is hosting HTTP and the certificate is self-signed, you must modify `daemon.json` on each work node of your cluster. For information, see https://docs.docker.com/registry/insecure/#deploy-a-plain-http-registry.
|
||||
2. If your pod references an image under a private project, you must create a secret with the credentials of a user who has permission to pull images from the project. For information, see https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/.
|
||||
|
||||
## Configure Notary Content Trust
|
||||
|
||||
In harbor.yml, make sure https is enabled, and the attributes `ssl_cert` and `ssl_cert_key` are pointed to valid certificates. For more information about generating https certificate please refer to: [Configuring HTTPS for Harbor](configure_https.md)
|
||||
Make sure that `https` is enabled in `harbor.yml` and the attributes `ssl_cert` and `ssl_cert_key` point to valid certificates. For more information about generating a HTTPS certificate, see [Configure HTTPS Access to Harbor](../install_config/configure_https.md).
|
||||
|
||||
### Copy Root Certificate
|
||||
### Copy the Root Certificate
|
||||
|
||||
Suppose the Harbor instance is hosted on a machine `192.168.0.5`
|
||||
If you are using a self-signed certificate, make sure to copy the CA root cert to `/etc/docker/certs.d/192.168.0.5/` and `~/.docker/tls/192.168.0.5:4443/`
|
||||
If Harbor instance is hosted at 192.168.0.5, ff you are using a self-signed certificate, copy the Harbor CA root cert to `/etc/docker/certs.d/192.168.0.5/` and `~/.docker/tls/192.168.0.5:4443/` on the machine on which you run the Docker client.
|
||||
|
||||
### Enable Docker Content Trust
|
||||
|
||||
It can be done via setting environment variables:
|
||||
You can enable content trust by setting the following environment variables on the machine on which you run the Docker client.
|
||||
|
||||
```
|
||||
export DOCKER_CONTENT_TRUST=1
|
||||
export DOCKER_CONTENT_TRUST_SERVER=https://192.168.0.5:4443
|
||||
```
|
||||
|
||||
### Set alias for notary (optional)
|
||||
### Set Alias for Notary (optional)
|
||||
|
||||
Because by default the local directory for storing meta files for notary client is different from docker client. If you want to use notary client to manipulate the keys/meta files generated by Docker Content Trust, please set the alias to reduce the effort:
|
||||
By default the local directory for storing meta files for the Notary client is different from the one for the Docker client. To simplify the use of the Notary client to manipulate the keys/meta files that are generated by Docker content trust, you can set an alias.
|
||||
|
||||
```
|
||||
alias notary="notary -s https://192.168.0.5:4443 -d ~/.docker/trust --tlscacert /etc/docker/certs.d/192.168.0.5/ca.crt"
|
||||
|
||||
@ -1,15 +1,23 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Retagging Images
|
||||
|
||||
Images retag helps users to tag images in Harbor, images can be tagged to different repositories and projects, as long as the users have sufficient permissions. For example,
|
||||
You can retag images in Harbor. Users with sufficient privileges can retag images to different repositories and projects. For example, you can retag images as follows:
|
||||
|
||||
```
|
||||
release/app:stg --> release/app:prd
|
||||
develop/app:v1.0 --> release/app:v1.0
|
||||
```
|
||||
To retag an image, users should have read permission (guest role or above) to the source project and write permission (developer role or above) to the target project.
|
||||
- `release/app:stg` --> `release/app:prd`
|
||||
- `develop/app:v1.0` --> `release/app:v1.0`
|
||||
|
||||
In Harbor portal, select the image you'd like to retag, and click the enabled `Retag` button to open the retag dialog.
|
||||
To retag an image, you must have read permission (guest role or above) in the source project and write permission (developer role or above) in the target project.
|
||||
|
||||
In the Harbor interface, select the image to retag, and click `Retag`.
|
||||
|
||||
|
||||
|
||||
In the retag dialog, project name, repository name and the new tag should be specified. On click the `CONFIRM` button, the new tag would be created instantly. You can check the new tag in the corresponding project.
|
||||
In the Retag windown, enter the project name, repository name, the new tag name, and click **Confirm**.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Using the API Explorer
|
||||
|
||||
Harbor integrated swagger UI from 1.8. That means all apis can be invoked through UI. Normally, user have 2 ways to navigate to API Explorer.
|
||||
@ -8,3 +12,8 @@ Harbor integrated swagger UI from 1.8. That means all apis can be invoked throug
|
||||
|
||||
2. User can navigate to swagger page by ip address by router "devcenter". For example: https://10.192.111.118/devcenter. After go to the page, need to click "authorize" button to give basic authentication to all apis. All apis will be invoked with the authorized user authorization.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
|
||||
@ -1,3 +1,15 @@
|
||||
# Working with Images and Tags
|
||||
|
||||
This section describes how to work with images and tags in Harbor.
|
||||
|
||||
- [Pulling and Pushing Images](pulling_pushing_images.md)
|
||||
- [Create Labels](create_labels.md)
|
||||
- [Retag Images](retagging_images.md)
|
||||
- [Create Tag Retention Rules](create_tag_retention_rules.md)
|
||||
- [Create Tag Immutability Rules](create_tag_immutability_rules.md)
|
||||
- [Manage Kubernetes Packages with Helm Charts](managing_helm_charts.md)
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
@ -1,46 +1,20 @@
|
||||
## Table of Content
|
||||
# User and Developer Documentation
|
||||
|
||||
### User documents
|
||||
For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
**[Installation and Configuration Guide](installation_guide.md)
|
||||
Read this first!**
|
||||
Guide for Harbor online installer and offline installer.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
|
||||
**[Harbor User Guide](user_guide.md)**
|
||||
How to use Harbor to manage images, projects, replications and users.
|
||||
See also the [Harbor Architecture Overview](https://github.com/vmware/harbor/wiki/Architecture-Overview-of-Harbor).
|
||||
|
||||
[Configuring HTTPS for Harbor](configure_https.md)
|
||||
Configure security connection between Harbor and Docker client.
|
||||
# Articles from the community
|
||||
|
||||
[Upgrade and Data Migration Guide](migration_guide.md)
|
||||
Data migration may be needed when upgrading Harbor to a newer version.
|
||||
[Python SDK](../contrib/registryapi)
|
||||
|
||||
[Deploy Harbor on Kubernetes](kubernetes_deployment.md)
|
||||
Guide to deploy Harbor on Kubernetes. (maintained by community)
|
||||
[Harbor CLI](https://github.com/int32bit/harborclient)
|
||||
|
||||
### Developer documents
|
||||
[Deploy Harbor using Docker Machine](../contrib/deploying_using_docker_machine.md)
|
||||
|
||||
[Architecture Overview of Harbor](https://github.com/vmware/harbor/wiki/Architecture-Overview-of-Harbor)
|
||||
Developers read this first.
|
||||
|
||||
[Build Harbor from Source](compile_guide.md)
|
||||
How to build Harbor from source code.
|
||||
|
||||
[Harbor API Specs by Swagger](configure_swagger.md)
|
||||
Use Swagger to find out the specs of Harbor API.
|
||||
|
||||
[Internationalization Guide](developer_guide_i18n.md)
|
||||
How to add your local language to Harbor.
|
||||
|
||||
[Python SDK](../contrib/registryapi) (by community)
|
||||
|
||||
[Harbor CLI](https://github.com/int32bit/harborclient) (by community)
|
||||
|
||||
[Deploy Harbor using Docker Machine](../contrib/deploying_using_docker_machine.md) ( by community)
|
||||
|
||||
[Configuring Harbor as a local registry mirror](../contrib/Configure_mirror.md) (by community)
|
||||
|
||||
### Articles from the community
|
||||
[Configuring Harbor as a local registry mirror](../contrib/Configure_mirror.md)
|
||||
|
||||
[Remote site replicated Docker Registries with VMware Harbor](http://www.vmtocloud.com/remote-site-replicated-docker-registries-with-vmware-harbor/)
|
||||
|
||||
|
||||
@ -1,178 +1,3 @@
|
||||
## Introduction
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
This guide provides instructions for developers to build and run Harbor from source code.
|
||||
|
||||
## Step 1: Prepare for a build environment for Harbor
|
||||
|
||||
Harbor is deployed as several Docker containers and most of the code is written in Go language. The build environment requires Docker, Docker Compose and golang development environment. Please install the below prerequisites:
|
||||
|
||||
| Software | Required Version |
|
||||
| -------------- | ---------------- |
|
||||
| docker | 17.05 + |
|
||||
| docker-compose | 1.18.0 + |
|
||||
| python | 2.7 + |
|
||||
| git | 1.9.1 + |
|
||||
| make | 3.81 + |
|
||||
| golang\* | 1.7.3 + |
|
||||
|
||||
\*optional, required only if you use your own Golang environment.
|
||||
|
||||
## Step 2: Getting the source code
|
||||
|
||||
```sh
|
||||
$ git clone https://github.com/goharbor/harbor
|
||||
```
|
||||
|
||||
## Step 3: Building and installing Harbor
|
||||
|
||||
### Configuration
|
||||
|
||||
Edit the file **make/harbor.yml** and make necessary configuration changes such as hostname, admin password and mail server. Refer to **[Installation and Configuration Guide](installation_guide.md#configuring-harbor)** for more info.
|
||||
|
||||
```sh
|
||||
$ cd harbor
|
||||
$ vi make/harbor.yml
|
||||
```
|
||||
|
||||
### Compiling and Running
|
||||
|
||||
You can compile the code by one of the three approaches:
|
||||
|
||||
#### I. Build with official Golang image
|
||||
|
||||
- Get official Golang image from docker hub:
|
||||
|
||||
```sh
|
||||
$ docker pull golang:1.13.4
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor without Notary:
|
||||
|
||||
```sh
|
||||
$ make install GOBUILDIMAGE=golang:1.13.4 COMPILETAG=compile_golangimage
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor with Notary:
|
||||
|
||||
```sh
|
||||
$ make install GOBUILDIMAGE=golang:1.13.4 COMPILETAG=compile_golangimage NOTARYFLAG=true
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor with Clair:
|
||||
|
||||
```sh
|
||||
$ make install GOBUILDIMAGE=golang:1.13.4 COMPILETAG=compile_golangimage CLAIRFLAG=true
|
||||
```
|
||||
|
||||
#### II. Compile code with your own Golang environment, then build Harbor
|
||||
|
||||
- Move source code to \$GOPATH
|
||||
|
||||
```sh
|
||||
$ mkdir $GOPATH/src/github.com/goharbor/
|
||||
$ cd ..
|
||||
$ mv harbor $GOPATH/src/github.com/goharbor/.
|
||||
```
|
||||
|
||||
- Build, install and run Harbor without Notary and Clair:
|
||||
|
||||
```sh
|
||||
$ cd $GOPATH/src/github.com/goharbor/harbor
|
||||
$ make install
|
||||
```
|
||||
|
||||
- Build, install and run Harbor with Notary and Clair:
|
||||
|
||||
```sh
|
||||
$ cd $GOPATH/src/github.com/goharbor/harbor
|
||||
$ make install -e NOTARYFLAG=true CLAIRFLAG=true
|
||||
```
|
||||
|
||||
### Verify your installation
|
||||
|
||||
If everything worked properly, you can get the below message:
|
||||
|
||||
```sh
|
||||
...
|
||||
Start complete. You can visit harbor now.
|
||||
```
|
||||
|
||||
Refer to [Installation and Configuration Guide](installation_guide.md#managing-harbors-lifecycle) for more information about managing your Harbor instance.
|
||||
|
||||
## Appendix
|
||||
|
||||
- Using the Makefile
|
||||
|
||||
The `Makefile` contains these configurable parameters:
|
||||
|
||||
| Variable | Description |
|
||||
| ------------------- | ---------------------------------------------------------------- |
|
||||
| BASEIMAGE | Container base image, default: photon |
|
||||
| DEVFLAG | Build model flag, default: dev |
|
||||
| COMPILETAG | Compile model flag, default: compile_normal (local golang build) |
|
||||
| NOTARYFLAG | Notary mode flag, default: false |
|
||||
| CLAIRFLAG | Clair mode flag, default: false |
|
||||
| HTTPPROXY | NPM http proxy for Clarity UI builder |
|
||||
| REGISTRYSERVER | Remote registry server IP address |
|
||||
| REGISTRYUSER | Remote registry server user name |
|
||||
| REGISTRYPASSWORD | Remote registry server user password |
|
||||
| REGISTRYPROJECTNAME | Project name on remote registry server |
|
||||
| VERSIONTAG | Harbor images tag, default: dev |
|
||||
| PKGVERSIONTAG | Harbor online and offline version tag, default:dev |
|
||||
|
||||
- Predefined targets:
|
||||
|
||||
| Target | Description |
|
||||
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------- |
|
||||
| all | prepare env, compile binaries, build images and install images |
|
||||
| prepare | prepare env |
|
||||
| compile | compile ui and jobservice code |
|
||||
| compile_portal | compile portal code |
|
||||
| compile_ui | compile ui binary |
|
||||
| compile_jobservice | compile jobservice binary |
|
||||
| build | build Harbor docker images (default: using build_photon) |
|
||||
| build_photon | build Harbor docker images from Photon OS base image |
|
||||
| install | compile binaries, build images, prepare specific version of compose file and startup Harbor instance |
|
||||
| start | startup Harbor instance (set NOTARYFLAG=true when with Notary) |
|
||||
| down | shutdown Harbor instance (set NOTARYFLAG=true when with Notary) |
|
||||
| package_online | prepare online install package |
|
||||
| package_offline | prepare offline install package |
|
||||
| pushimage | push Harbor images to specific registry server |
|
||||
| clean all | remove binary, Harbor images, specific version docker-compose file, specific version tag and online/offline install package |
|
||||
| cleanbinary | remove ui and jobservice binary |
|
||||
| cleanimage | remove Harbor images |
|
||||
| cleandockercomposefile | remove specific version docker-compose |
|
||||
| cleanversiontag | remove specific version tag |
|
||||
| cleanpackage | remove online/offline install package |
|
||||
|
||||
#### EXAMPLE:
|
||||
|
||||
#### Push Harbor images to specific registry server
|
||||
|
||||
```sh
|
||||
$ make pushimage -e DEVFLAG=false REGISTRYSERVER=[$SERVERADDRESS] REGISTRYUSER=[$USERNAME] REGISTRYPASSWORD=[$PASSWORD] REGISTRYPROJECTNAME=[$PROJECTNAME]
|
||||
|
||||
```
|
||||
|
||||
**Note**: need add "/" on end of REGISTRYSERVER. If REGISTRYSERVER is not set, images will be pushed directly to Docker Hub.
|
||||
|
||||
```sh
|
||||
$ make pushimage -e DEVFLAG=false REGISTRYUSER=[$USERNAME] REGISTRYPASSWORD=[$PASSWORD] REGISTRYPROJECTNAME=[$PROJECTNAME]
|
||||
|
||||
```
|
||||
|
||||
#### Clean up binaries and images of a specific version
|
||||
|
||||
```sh
|
||||
$ make clean -e VERSIONTAG=[TAG]
|
||||
|
||||
```
|
||||
|
||||
**Note**: If new code had been added to Github, the git commit TAG will change. Better use this command to clean up images and files of previous TAG.
|
||||
|
||||
#### By default, the make process create a development build. To create a release build of Harbor, set the below flag to false.
|
||||
|
||||
```sh
|
||||
$ make XXXX -e DEVFLAG=false
|
||||
|
||||
```
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,194 +1,3 @@
|
||||
# Configuring Harbor with HTTPS Access
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
In versions up to and including 1.9.x, by default Harbor uses HTTP to serve registry requests. However, using HTTP is acceptable only in air-gapped test or development environments that do not have a connection to the external internet. Using HTTP in environments that are not air-gapped exposes you to man-in-the-middle attacks. In production environments, always use HTTPS. If you enable Content Trust with Notary to properly sign all images, you must use HTTPS.
|
||||
|
||||
Harbor uses an `nginx` instance as a reverse proxy for all services. You use the `prepare` script to configure `nginx` to enable HTTPS.
|
||||
|
||||
You can use certificates that are signed by a trusted third-party CA, or you can use self-signed certificates. The following sections describe how to create a CA, and how to use your CA to sign a server certificate and a client certificate.
|
||||
|
||||
## Getting Certificate Authority
|
||||
|
||||
```
|
||||
openssl genrsa -out ca.key 4096
|
||||
```
|
||||
```
|
||||
openssl req -x509 -new -nodes -sha512 -days 3650 \
|
||||
-subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=yourdomain.com" \
|
||||
-key ca.key \
|
||||
-out ca.crt
|
||||
```
|
||||
|
||||
## Getting Server Certificate
|
||||
|
||||
Assuming that your registry's **hostname** is **yourdomain.com**, and that its DNS record points to the host where you are running Harbor. In production environment, you first should get a certificate from a CA. In a test or development environment, you can use your own CA. The certificate usually contains a .crt file and a .key file, for example, **yourdomain.com.crt** and **yourdomain.com.key**.
|
||||
|
||||
|
||||
|
||||
**1) Create your own Private Key:**
|
||||
|
||||
```
|
||||
openssl genrsa -out yourdomain.com.key 4096
|
||||
```
|
||||
|
||||
**2) Generate a Certificate Signing Request:**
|
||||
|
||||
If you use FQDN like **yourdomain.com** to connect your registry host, then you must use **yourdomain.com** as CN (Common Name).
|
||||
|
||||
```
|
||||
openssl req -sha512 -new \
|
||||
-subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=yourdomain.com" \
|
||||
-key yourdomain.com.key \
|
||||
-out yourdomain.com.csr
|
||||
```
|
||||
|
||||
**3) Generate the certificate of your registry host:**
|
||||
|
||||
Whether you're using FQDN like **yourdomain.com** or IP to connect your registry host, run this command to generate the certificate of your registry host which comply with Subject Alternative Name (SAN) and x509 v3 extension requirement:
|
||||
|
||||
**v3.ext**
|
||||
|
||||
```
|
||||
cat > v3.ext <<-EOF
|
||||
authorityKeyIdentifier=keyid,issuer
|
||||
basicConstraints=CA:FALSE
|
||||
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
|
||||
extendedKeyUsage = serverAuth
|
||||
subjectAltName = @alt_names
|
||||
|
||||
[alt_names]
|
||||
DNS.1=yourdomain.com
|
||||
DNS.2=yourdomain
|
||||
DNS.3=hostname
|
||||
EOF
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
openssl x509 -req -sha512 -days 3650 \
|
||||
-extfile v3.ext \
|
||||
-CA ca.crt -CAkey ca.key -CAcreateserial \
|
||||
-in yourdomain.com.csr \
|
||||
-out yourdomain.com.crt
|
||||
```
|
||||
|
||||
## Configuration and Installation
|
||||
|
||||
**1) Configure Server Certificate and Key for Harbor**
|
||||
|
||||
After obtaining the **yourdomain.com.crt** and **yourdomain.com.key** files,
|
||||
you can put them into directory such as ```/root/cert/```:
|
||||
|
||||
```
|
||||
cp yourdomain.com.crt /data/cert/
|
||||
cp yourdomain.com.key /data/cert/
|
||||
```
|
||||
|
||||
**2) Configure Server Certificate, Key and CA for Docker**
|
||||
|
||||
The Docker daemon interprets ```.crt``` files as CA certificates and ```.cert``` files as client certificates.
|
||||
|
||||
Convert server ```yourdomain.com.crt``` to ```yourdomain.com.cert```:
|
||||
|
||||
```
|
||||
openssl x509 -inform PEM -in yourdomain.com.crt -out yourdomain.com.cert
|
||||
```
|
||||
Delpoy ```yourdomain.com.cert```, ```yourdomain.com.key```, and ```ca.crt``` for Docker:
|
||||
|
||||
```
|
||||
cp yourdomain.com.cert /etc/docker/certs.d/yourdomain.com/
|
||||
cp yourdomain.com.key /etc/docker/certs.d/yourdomain.com/
|
||||
cp ca.crt /etc/docker/certs.d/yourdomain.com/
|
||||
```
|
||||
|
||||
The following illustrates a configuration with custom certificates:
|
||||
|
||||
|
||||
```
|
||||
/etc/docker/certs.d/
|
||||
└── yourdomain.com:port
|
||||
├── yourdomain.com.cert <-- Server certificate signed by CA
|
||||
├── yourdomain.com.key <-- Server key signed by CA
|
||||
└── ca.crt <-- Certificate authority that signed the registry certificate
|
||||
```
|
||||
|
||||
Notice that you may need to trust the certificate at OS level. Please refer to the [Troubleshooting](#Troubleshooting) section below.
|
||||
|
||||
**3) Configure Harbor**
|
||||
|
||||
Edit the file `harbor.yml`, update the hostname and uncomment the https block, and update the attributes `certificate` and `private_key`:
|
||||
|
||||
```yaml
|
||||
#set hostname
|
||||
hostname: yourdomain.com
|
||||
|
||||
http:
|
||||
port: 80
|
||||
|
||||
https:
|
||||
# https port for harbor, default is 443
|
||||
port: 443
|
||||
# The path of cert and key files for nginx
|
||||
certificate: /data/cert/yourdomain.com.crt
|
||||
private_key: /data/cert/yourdomain.com.key
|
||||
|
||||
......
|
||||
|
||||
```
|
||||
|
||||
Generate configuration files for Harbor:
|
||||
|
||||
```
|
||||
./prepare
|
||||
```
|
||||
|
||||
If Harbor is already running, stop and remove the existing instance. Your image data remain in the file system
|
||||
|
||||
```
|
||||
docker-compose down -v
|
||||
```
|
||||
Finally, restart Harbor:
|
||||
|
||||
```
|
||||
docker-compose up -d
|
||||
```
|
||||
After setting up HTTPS for Harbor, you can verify it by the following steps:
|
||||
|
||||
* Open a browser and enter the address: https://yourdomain.com. It should display the user interface of Harbor.
|
||||
|
||||
* Notice that some browser may still shows the warning regarding Certificate Authority (CA) unknown for security reason even though we signed certificates by self-signed CA and deploy the CA to the place mentioned above. It is because self-signed CA essentially is not a trusted third-party CA. You can import the CA to the browser on your own to solve the warning.
|
||||
|
||||
* On a machine with Docker daemon, make sure the option "-insecure-registry" for https://yourdomain.com is not present.
|
||||
|
||||
* If you mapped nginx port 443 to another port, then you should instead create the directory ```/etc/docker/certs.d/yourdomain.com:port``` (or your registry host IP:port). Then run any docker command to verify the setup, e.g.
|
||||
|
||||
|
||||
```
|
||||
docker login yourdomain.com
|
||||
```
|
||||
If you've mapped nginx 443 port to another, you need to add the port to login, like below:
|
||||
|
||||
```
|
||||
docker login yourdomain.com:port
|
||||
```
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
1. You may get an intermediate certificate from a certificate issuer. In this case, you should merge the intermediate certificate with your own certificate to create a certificate bundle. You can achieve this by the below command:
|
||||
|
||||
```
|
||||
cat intermediate-certificate.pem >> yourdomain.com.crt
|
||||
```
|
||||
2. On some systems where docker daemon runs, you may need to trust the certificate at OS level.
|
||||
On Ubuntu, this can be done by below commands:
|
||||
|
||||
```sh
|
||||
cp yourdomain.com.crt /usr/local/share/ca-certificates/yourdomain.com.crt
|
||||
update-ca-certificates
|
||||
```
|
||||
|
||||
On Red Hat (CentOS etc), the commands are:
|
||||
|
||||
```sh
|
||||
cp yourdomain.com.crt /etc/pki/ca-trust/source/anchors/yourdomain.com.crt
|
||||
update-ca-trust
|
||||
```
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,71 +1,3 @@
|
||||
# View and test Harbor REST API via Swagger
|
||||
A Swagger file is provided for viewing and testing Harbor REST API.
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
### Viewing Harbor REST API
|
||||
* Open the file **swagger.yaml** under the _docs_ directory in Harbor project;
|
||||
* Paste all its content into the online Swagger Editor at http://editor.swagger.io. The descriptions of Harbor API will be shown on the right pane of the page.
|
||||
|
||||
|
||||
|
||||
### Testing Harbor REST API
|
||||
From time to time, you may need to mannually test Harbor REST API. You can deploy the Swagger file into Harbor's service node. Suppose you install Harbor through online or offline installer, you should have a Harbor directory after you un-tar the installer, such as **~/harbor**.
|
||||
|
||||
**Caution:** When using Swagger to send REST requests to Harbor, you may alter the data of Harbor accidentally. For this reason, it is NOT recommended using Swagger against a production Harbor instance.
|
||||
|
||||
* Download _prepare-swagger.sh_ and _swagger.yaml_ under the _docs_ directory to your local Harbor directory, e.g. **~/harbor**.
|
||||
```sh
|
||||
wget https://raw.githubusercontent.com/goharbor/harbor/master/docs/prepare-swagger.sh https://raw.githubusercontent.com/goharbor/harbor/master/api/harbor/swagger.yaml
|
||||
```
|
||||
* Edit the script file _prepare-swagger.sh_.
|
||||
```sh
|
||||
vi prepare-swagger.sh
|
||||
```
|
||||
* Change the SCHEME to the protocol scheme of your Harbor server.
|
||||
```sh
|
||||
SCHEME=<HARBOR_SERVER_SCHEME>
|
||||
```
|
||||
* Change the SERVER_IP to the IP address of your Harbor server.
|
||||
```sh
|
||||
SERVER_IP=<HARBOR_SERVER_DOMAIN>
|
||||
```
|
||||
* Change the file mode.
|
||||
```sh
|
||||
chmod +x prepare-swagger.sh
|
||||
````
|
||||
* Run the shell script. It downloads a Swagger package and extracts files into the _../static_ directory.
|
||||
```sh
|
||||
./prepare-swagger.sh
|
||||
```
|
||||
* Edit the _docker-compose.yml_ file under your local Harbor directory.
|
||||
```sh
|
||||
vi docker-compose.yml
|
||||
```
|
||||
* Add two lines to the file _docker-compose.yml_ under the section _ui.volumes_.
|
||||
```docker
|
||||
...
|
||||
ui:
|
||||
...
|
||||
volumes:
|
||||
- ./common/config/ui/app.conf:/etc/core/app.conf:z
|
||||
- ./common/config/ui/private_key.pem:/etc/core/private_key.pem:z
|
||||
- /data/secretkey:/etc/core/key:z
|
||||
- /data/ca_download/:/etc/core/ca/:z
|
||||
## add two lines as below ##
|
||||
- ../src/ui/static/vendors/swagger-ui-2.1.4/dist:/harbor/static/vendors/swagger
|
||||
- ../src/ui/static/resources/yaml/swagger.yaml:/harbor/static/resources/yaml/swagger.yaml
|
||||
...
|
||||
```
|
||||
* Recreate Harbor containers
|
||||
```docker
|
||||
docker-compose down -v && docker-compose up -d
|
||||
```
|
||||
|
||||
* Because a session ID is usually required by Harbor API, **you should log in first from a browser.**
|
||||
* Open another tab in the same browser so that the session is shared between tabs.
|
||||
* Enter the URL of the Swagger page in Harbor as below. The ```<HARBOR_SERVER>``` should be replaced by the IP address or the hostname of the Harbor server.
|
||||
```
|
||||
http://<HARBOR_SERVER>/static/vendors/swagger/index.html
|
||||
```
|
||||
* You should see a Swagger UI page with Harbor API _swagger.yaml_ file loaded in the same domain, **be aware that your REST request submitted by Swagger may change the data of Harbor**.
|
||||
|
||||
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,112 +1,3 @@
|
||||
# Config Harbor user settings by command line
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
After release 1.8.0, all user settings are separated from system settings, it can not be configured in config file anymore. Users need to configure it with admin privileges in web console or via HTTP request.
|
||||
|
||||
`curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki <Harbor Server URL>/api/configurations -d'{"<item_name>":"<item_value>"}'`
|
||||
|
||||
Get current configurations
|
||||
|
||||
`curl -u "<username>:<password>" -H "Content-Type: application/json" -ki <Harbor Server URL>/api/configurations`
|
||||
|
||||
## Sample config commands:
|
||||
|
||||
1. Update Harbor to use LDAP auth
|
||||
|
||||
Command
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"auth_mode":"ldap_auth"}'
|
||||
```
|
||||
Output
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:22:02 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=a5803a1265e2b095cf65ce1d8bbd79b1; Path=/; HttpOnly
|
||||
```
|
||||
|
||||
1. Restrict project creation to admin only
|
||||
|
||||
Command
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"project_creation_restriction":"adminonly"}'
|
||||
```
|
||||
|
||||
Output
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:24:32 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=b7925eaf7af53bdefb13bdcae201a14a; Path=/; HttpOnly
|
||||
```
|
||||
|
||||
1. Update the token expiration time
|
||||
|
||||
Command
|
||||
```shell
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"token_expiration":"300"}'
|
||||
```
|
||||
|
||||
Output
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Server: nginx
|
||||
Date: Wed, 08 May 2019 08:23:38 GMT
|
||||
Content-Type: text/plain; charset=utf-8
|
||||
Content-Length: 0
|
||||
Connection: keep-alive
|
||||
Set-Cookie: sid=cc1bc93ffa2675253fc62b4bf3d9de0e; Path=/; HttpOnly
|
||||
```
|
||||
|
||||
## Harbor user settings
|
||||
|
||||
| Configure item name | Description | Type | Required | Default Value |
|
||||
| ------------ |------------ | ---- | ----- | ----- |
|
||||
auth_mode | Authentication mode, it can be db_auth, ldap_auth, uaa_auth or oidc_auth | string
|
||||
email_from | Email from | string | required (email feature)
|
||||
email_host | Email server | string | required (email feature)
|
||||
email_identity | Email identity | string | optional (email feature)
|
||||
email_password | Email password | string | required (email feature)
|
||||
email_insecure | Email verify certificate, true or false |boolean | optional (email feature) | false
|
||||
email_port | Email server port | number | required (email feature)
|
||||
email_ssl | Email SSL | boolean | optional | false
|
||||
email_username | Email username | string | required (email feature)
|
||||
ldap_url | LDAP URL | string | required |
|
||||
ldap_base_dn | LDAP base DN | string | required(ldap_auth)
|
||||
ldap_filter | LDAP filter | string | optional
|
||||
ldap_scope | LDAP search scope, 0-Base Level, 1- One Level, 2-Sub Tree | number | optional | 2-Sub Tree
|
||||
ldap_search_dn | LDAP DN to search LDAP users| string | required(ldap_auth)
|
||||
ldap_search_password | LDAP DN's password |string | required(ldap_auth)
|
||||
ldap_timeout | LDAP connection timeout | number | optional | 5
|
||||
ldap_uid | LDAP attribute to indicate the username in Harbor | string | optional | cn
|
||||
ldap_verify_cert | Verify cert when create SSL connection with LDAP server, true or false | boolean | optional | true
|
||||
ldap_group_admin_dn | LDAP Group Admin DN | string | optional
|
||||
ldap_group_attribute_name | LDAP Group Attribute, the LDAP attribute indicate the groupname in Harbor, it can be gid or cn | string | optional | cn
|
||||
ldap_group_base_dn | The Base DN which to search the LDAP groups | string | required(ldap_auth and LDAP group)
|
||||
ldap_group_search_filter | The filter to search LDAP groups | string | optional
|
||||
ldap_group_search_scope | LDAP group search scope, 0-Base Level, 1- One Level, 2-Sub Tree | number | optional | 2-Sub Tree|
|
||||
ldap_group_membership_attribute | LDAP group membership attribute, to indicate the group membership, it can be memberof, or ismemberof | string | optional | memberof
|
||||
project_creation_restriction | The option to indicate user can be create object, it can be everyone, adminonly | string | optional | everyone
|
||||
read_only | The option to set repository read only, it can be true or false | boolean | optional | false
|
||||
self_registration | User can register account in Harbor, it can be true or false | boolean | optional| true
|
||||
token_expiration | Security token expirtation time in minutes | number |optional| 30
|
||||
uaa_client_id | UAA client ID | string | required(uaa_auth)
|
||||
uaa_client_secret | UAA certificate | string | required(uaa_auth)
|
||||
uaa_endpoint | UAA endpoint | string | required(uaa_auth)
|
||||
uaa_verify_cert | UAA verify cert, true or false | boolean | optional | true
|
||||
oidc_name | name for OIDC authentication | string | required(oidc_auth)
|
||||
oidc_endpoint | endpoint for OIDC auth | string | required(oidc_auth)
|
||||
oidc_client_id | client id for OIDC auth | string | required(oidc_auth)
|
||||
oidc_client_secret | client secret for OIDC auth |string | required(oidc_auth)
|
||||
oidc_scope | scope for OIDC auth | string| required(oidc_auth)
|
||||
oidc_verify_cert | verify cert for OIDC auth, true or false | boolean | optional| true
|
||||
robot_token_duration | Robot token expiration time in minutes | number | optional | 43200 (30days)
|
||||
|
||||
|
||||
|
||||
**Note:** Both boolean and number can be enclosed with double quote in the request json, for example: `123`, `"123"`, `"true"` or `true` is OK.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,38 +1,3 @@
|
||||
# Customize the look & feel of Harbor
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
The primary look & feel of Harbor supports to be customized with several simple steps. All the relevant customization in configurations are saved in the `setting.json` file under `$HARBOR_DIR/src/portal/src` folder with `json` format and will be loaded when Harbor is launched.
|
||||
|
||||
## Configure
|
||||
Open the `setting.json` file, you'll see the default content as shown below:
|
||||
|
||||
```
|
||||
{
|
||||
"headerBgColor": "#004a70",
|
||||
"headerLogo": "",
|
||||
"loginBgImg": "",
|
||||
"appTitle": "",
|
||||
"product": {
|
||||
"name": "Harbor",
|
||||
"introduction": {
|
||||
"zh-cn": "",
|
||||
"es-es": "",
|
||||
"en-us": ""
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Change the values of configuration if you want to override the default style to your own. Here are references:
|
||||
|
||||
* **headerBgColor**: Background color of the page header, support either HEX or RGB value. e.g: `#004a70` and `rgb(210,110,235)`.
|
||||
* **headerLogo**: Name path of the logo image in the header, e.g: 'logo.png'. The image file should be put in the `images` folder.
|
||||
* **loginBgImg**: Name path of the background image displayed in the login page, e.g: 'login_bg.png'. The image file should be put in the `images` folder. Suggest the size of this image should be bigger than 800px*600px.
|
||||
* **Product**: Contain metadata / description of the product.
|
||||
- **title**: The full product title displayed in the login page.
|
||||
- **company**: Name of the company publishing the product.
|
||||
- **name**: Name of the product.
|
||||
- **introductions**: The introduction about the product with different languages, which are displayed in the `About` dialog.
|
||||
|
||||
## Build
|
||||
|
||||
Once the `setting.json` configurations has been updated, re-[build](#configure) your product to apply the new changes.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,60 +1,3 @@
|
||||
# Customize Harbor token service with your key and certificate
|
||||
|
||||
Harbor requires Docker client to access the Harbor registry with a token. The procedure to generate a token is like [Docker Registry v2 authentication](https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md). Firstly, you should make a request to the token service for a token. The token is signed by the private key. After that, you make a new request with the token to the Harbor registry, Harbor registry will verify the token with the public key in the rootcert bundle. Then Harbor registry will authorize the Docker client to push/pull images.
|
||||
|
||||
By default, Harbor uses default private key and certificate in authentication. Also, you can customize your configuration with your own key and certificate with the following steps:
|
||||
|
||||
1.If you already have a certificate, go to step 3.
|
||||
|
||||
2.If not, you can generate a root certificate using openSSL with following commands:
|
||||
|
||||
**1)Generate a private key:**
|
||||
|
||||
```sh
|
||||
$ openssl genrsa -out private_key.pem 4096
|
||||
```
|
||||
|
||||
**2)Generate a certificate:**
|
||||
```sh
|
||||
$ openssl req -new -x509 -key private_key.pem -out root.crt -days 3650
|
||||
```
|
||||
You are about to be asked to enter information that will be incorporated into your certificate request.
|
||||
What you are about to enter is what is called a Distinguished Name or a DN.
|
||||
There are quite a few fields but you can leave some blank
|
||||
For some fields there will be a default value,
|
||||
If you enter '.', the field will be left blank. Following are what you're asked to enter.
|
||||
|
||||
Country Name (2 letter code) [AU]:
|
||||
|
||||
State or Province Name (full name) [Some-State]:
|
||||
|
||||
Locality Name (eg, city) []:
|
||||
|
||||
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
|
||||
|
||||
Organizational Unit Name (eg, section) []:
|
||||
|
||||
Common Name (eg, server FQDN or YOUR name) []:
|
||||
|
||||
Email Address []:
|
||||
|
||||
After you execute these two commands, you will see private_key.pem and root.crt in the **current directory**, just type "ls", you'll see them.
|
||||
|
||||
3.Refer to [Installation Guide](https://github.com/goharbor/harbor/blob/master/docs/installation_guide.md) to install Harbor, After you execute ./prepare, Harbor generates several config files. We need to replace the original private key and certificate with your own key and certificate.
|
||||
|
||||
4.Replace the default key and certificate. Assume that you key and certificate are in the directory /root/cert, following are what you should do:
|
||||
|
||||
```
|
||||
$ cd config/ui
|
||||
$ cp /root/cert/private_key.pem private_key.pem
|
||||
$ cp /root/cert/root.crt ../registry/root.crt
|
||||
```
|
||||
|
||||
5.After these, go back to the make directory, you can start Harbor using following command:
|
||||
```
|
||||
$ docker-compose up -d
|
||||
```
|
||||
|
||||
6.Then you can push/pull images to see if your own certificate works. Please refer [User Guide](https://github.com/goharbor/harbor/blob/master/docs/user_guide.md) for more info.
|
||||
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,21 +1,3 @@
|
||||
# Demo Server Guide
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
**Important!**
|
||||
- Please note that this demo server is **ONLY** to be used for experimenting with Harbor functionality.
|
||||
- Please **DO NOT** upload any sensitive images to this server.
|
||||
- This is **NOT** a production environment and we are not responsible for any loss of data, functionality, or service.
|
||||
- We will **CLEAN AND RESET** the server every **couple of days**.
|
||||
- You can only experience the non-admin functionalities on this server. Please follow the **[Installation Guide](installation_guide.md)** to set up a Harbor server to try the more advanced features.
|
||||
- Please do not push large images (>100MB) as the server has limited storage.
|
||||
|
||||
If you encounter any problems during using the demo server, please open an issue or ping us on [Slack](https://github.com/goharbor/harbor#community).
|
||||
|
||||
**Usage**
|
||||
|
||||
- The address of the demo server is [https://demo.goharbor.io](https://demo.goharbor.io)
|
||||
- You can register as a new user
|
||||
- Then you can use the account/password created in step 2 to log in
|
||||
```
|
||||
docker login demo.goharbor.io
|
||||
```
|
||||
You can refer to the [User Guide](user_guide.md) for more details on how to use Harbor.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,58 +1,3 @@
|
||||
## Developer's Guide for Internationalization (i18n)
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
*NOTE: All the files you created should use UTF-8 encoding.*
|
||||
|
||||
### Steps to localize the UI in your language
|
||||
|
||||
1. In the folder `src/portal/src/i18n/lang`, copy json file `en-us-lang.json` to a new file and rename it to `<language>-<locale>-lang.json` .
|
||||
|
||||
The file contains a JSON object including all the key-value pairs of UI strings:
|
||||
```
|
||||
{
|
||||
"APP_TITLE": {
|
||||
"VMW_HARBOR": "Harbor",
|
||||
"HARBOR": "Harbor",
|
||||
...
|
||||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
In the file `<language>-<locale>-lang.json`, translate all the values into your language. Do not change any keys.
|
||||
|
||||
2. After creating your language file, you should add it to the language supporting list.
|
||||
|
||||
Locate the file `src/portal/src/app/shared/shared.const.ts`.
|
||||
Append `<language>-<locale>` to the language supporting list:
|
||||
```
|
||||
export const supportedLangs = ['en-us', 'zh-cn', '<language>-<locale>'];
|
||||
```
|
||||
Define the language display name and append it to the name list:
|
||||
```
|
||||
export const languageNames = {
|
||||
"en-us": "English",
|
||||
"zh-cn": "中文简体",
|
||||
"<language>-<locale>": "<DISPLAY_NAME>"
|
||||
};
|
||||
```
|
||||
|
||||
**NOTE: Don't miss the comma before the new key-value item you've added.**
|
||||
|
||||
3. Enable the new language in the view.
|
||||
|
||||
Locate the file `src/portal/src/app/base/navigator/navigator.component.html` and then find the following code piece:
|
||||
```
|
||||
<div class="dropdown-menu">
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("en-us")' [class.lang-selected]='matchLang("en-us")'>English</a>
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("zh-cn")' [class.lang-selected]='matchLang("zh-cn")'>中文简体</a>
|
||||
</div>
|
||||
```
|
||||
Add new menu item for your language:
|
||||
```
|
||||
<div class="dropdown-menu">
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("en-us")' [class.lang-selected]='matchLang("en-us")'>English</a>
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("zh-cn")' [class.lang-selected]='matchLang("zh-cn")'>中文简体</a>
|
||||
<a href="javascript:void(0)" clrDropdownItem (click)='switchLanguage("<language>-<locale>")' [class.lang-selected]='matchLang("<language>-<locale>")'>DISPLAY_NAME</a>
|
||||
</div>
|
||||
```
|
||||
|
||||
4. Next, please refer [compile guideline](compile_guide.md) to rebuild and restart Harbor.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,49 +1,3 @@
|
||||
# Harbor Compatibility List
|
||||
|
||||
This document provides compatibility information for all Harbor components.
|
||||
|
||||
## Replication Adapters
|
||||
|
||||
| | Registries | Pull Mode | Push Mode | Introduced in Release | Automated Pipeline Covered |
|
||||
|-----|------------------|-----------|-----------|-----------------------|---------------------------|
|
||||
| [Harbor](https://goharbor.io/)| ||| V1.8 | Y |
|
||||
| [distribution](https://github.com/docker/distribution) | ||| V1.8 | Y |
|
||||
| [docker hub](https://hub.docker.com/) | ||| V1.8 | Y |
|
||||
| [Huawei SWR](https://www.huaweicloud.com/en-us/product/swr.html) | ||| V1.8 | N |
|
||||
| [GCR](https://cloud.google.com/container-registry/) | ||| V1.9 | Y |
|
||||
| [ECR](https://aws.amazon.com/ecr/) | ||| V1.9 | Y |
|
||||
| [ACR](https://azure.microsoft.com/en-us/services/container-registry/) | ||| V1.9 | N |
|
||||
| [AliCR](https://www.alibabacloud.com/product/container-registry) | ||| V1.9 | N |
|
||||
| [Helm Hub](https://hub.helm.sh/) | || N/A | V1.9 | N |
|
||||
| [Artifactory](https://jfrog.com/artifactory/) | ||  | V1.10 | N |
|
||||
| [Quay](https://github.com/quay/quay) | ||  | V1.10 | N |
|
||||
| [GitLab Registry](https://docs.gitlab.com/ee/user/packages/container_registry/) | ||  | V1.10 | N |
|
||||
|
||||
**Notes**:
|
||||
|
||||
* `Pull` mode replicates artifacts from the specified source registries into Harbor.
|
||||
* `Push` mode replicates artifacts from Harbor to the specified target registries.
|
||||
|
||||
## OIDC Adapters
|
||||
|
||||
| | OIDC Providers | Officially Verified | End User Verified | Verified in Release |
|
||||
|---|-----------------|---------------------|---------------------|-----------------------|
|
||||
| [Google Identity](https://developers.google.com/identity/protocols/OpenIDConnect) | |  | |V1.9|
|
||||
| [Dex](https://github.com/dexidp/dex) |  | | | V1.9 |
|
||||
| [Ping Identity](https://www.pingidentity.com) |  | | | V1.9 |
|
||||
| [Keycloak](https://www.keycloak.org/) |  |  | | V1.10 |
|
||||
| [Auth0](https://auth0.com/) |  |  | | V1.10 |
|
||||
|
||||
## Scanner Adapters
|
||||
|
||||
| | Scanners | Providers | As Default | Onboard in Release |
|
||||
|---|----------|-----------|------------|--------------------|
|
||||
| [Clair](https://github.com/goharbor/harbor-scanner-clair) || CentOS || v1.10 |
|
||||
| [Anchore](https://github.com/anchore/harbor-scanner-adapter) | | Anchore | N | v1.10 |
|
||||
| [Trivy](https://github.com/aquasecurity/harbor-scanner-trivy)|| Aqua | N | v1.10 |
|
||||
| [Dosec](https://github.com/dosec-cn/harbor-scanner) || Dosec | N | v1.10 |
|
||||
|
||||
**Notes:**
|
||||
|
||||
* `As Default` means that the scanner is provided as a default option and can be deployed together with the main Harbor components by providing extra options during installation. You must install other scanners manually.
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,69 +1,3 @@
|
||||
## Update an offline Harbor instance with new vulnerability data
|
||||
|
||||
Harbor has integrated with Clair to scan vulnerabilities in images. When Harbor is installed in an environment without internet connection, Clair cannot fetch data from the public vulnerability database. Under this circumstance, Harbor system administrator needs to manually update the Clair database.
|
||||
|
||||
This document provides step-by-step instructions on updating Clair vulnerability database in Harbor.
|
||||
|
||||
**NOTE:** Harbor does not ship with any vulnerability data. For this reason, if Harbor cannot connect to Internet, the administrator must manually import vulnerability data to Harbor by using instructions given in this document.
|
||||
|
||||
### Preparation
|
||||
|
||||
A. You need to install an instance of Clair with internet connection. If you have another instance of Harbor with internet access, it also works.
|
||||
|
||||
B. Check whether your Clair instance has already updated the vulnerability database to the latest version. If it has not, wait for Clair to get the data from public endpoints.
|
||||
|
||||
- Use command `docker ps` to find out the container id of Clair.
|
||||
|
||||
- Run command `docker logs container_id` to check the log of the Clair container. If you are using Harbor you can find the latest Clair log under /var/log/harbor/2017-xx-xx/clair.log
|
||||
|
||||
- Look for logs that look like the below:
|
||||
```
|
||||
Jul 3 20:40:45 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:40:45.890364","updater name":"rhel"}
|
||||
Jul 3 20:40:46 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:40:46.768924","updater name":"alpine"}
|
||||
Jul 3 20:40:47 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:40:47.190982","updater name":"oracle"}
|
||||
Jul 3 20:41:07 172.18.0.1 clair[3516]: {"Event":"Debian buster is not mapped to any version number (eg. Jessie-\u003e8). Please update me.","Level":"warning","Location":"debian.go:128","Time":"2017-07-04 03:41:07.833720"}
|
||||
Jul 3 20:41:07 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 03:41:07.833975","updater name":"debian"}
|
||||
Jul 4 00:26:17 172.18.0.1 clair[3516]: {"Event":"finished fetching","Level":"info","Location":"updater.go:227","Time":"2017-07-04 07:26:17.596986","updater name":"ubuntu"}
|
||||
Jul 4 00:26:18 172.18.0.1 clair[3516]: {"Event":"adding metadata to vulnerabilities","Level":"info","Location":"updater.go:253","Time":"2017-07-04 07:26:18.060810"}
|
||||
Jul 4 00:38:05 172.18.0.1 clair[3516]: {"Event":"update finished","Level":"info","Location":"updater.go:198","Time":"2017-07-04 07:38:05.251580"}
|
||||
```
|
||||
- The phrase "finished fetching" indicates that Clair has finished a round of vulnerability update from an endpoint. Please make sure all five endpoints (rhel, alpine, oracle, debian, ubuntu) are updated correctly.
|
||||
|
||||
## Harbor version < 1.6
|
||||
|
||||
If you're using a version of Harbor prior to 1.6, you can access the correct instructions for your version using the following URL.
|
||||
https://github.com/goharbor/harbor/blob/v\<VERSION NUMBER>/docs/import_vulnerability_data.md
|
||||
|
||||
## Harbor version >= 1.6
|
||||
|
||||
Databased were consolidated in version 1.6 which moved the clair database to the harbor-db container and removed the clair-db container.
|
||||
|
||||
### Dumping vulnerability data
|
||||
|
||||
- Log in to the host (that is connected to Internet) where Clair database (Postgres) is running.
|
||||
- Dump Clair's vulnerability database by the following commands, two files (`vulnerability.sql` and `clear.sql`) are generated:
|
||||
|
||||
_NOTE: The container name 'clair-db' is a placeholder for the db container used by the internet connected instance of clair_
|
||||
|
||||
```
|
||||
$ docker exec clair-db /bin/sh -c "pg_dump -U postgres -a -t feature -t keyvalue -t namespace -t schema_migrations -t vulnerability -t vulnerability_fixedin_feature" > vulnerability.sql
|
||||
$ docker exec clair-db /bin/sh -c "pg_dump -U postgres -c -s" > clear.sql
|
||||
```
|
||||
|
||||
### Back up Harbor's Clair database
|
||||
Before importing the data, it is strongly recommended to back up the Clair database in Harbor.
|
||||
```
|
||||
$ docker exec harbor-db /bin/sh -c "pg_dump -U postgres -c" > all.sql
|
||||
```
|
||||
|
||||
### Update Harbor's Clair database
|
||||
Copy the `vulnerability.sql` and `clear.sql` to the host where Harbor is running on. Run the below commands to import the data to Harbor's Clair database:
|
||||
|
||||
```
|
||||
$ docker exec -i harbor-db psql -U postgres < clear.sql
|
||||
$ docker exec -i harbor-db psql -U postgres < vulnerability.sql
|
||||
```
|
||||
|
||||
### Rescanning images
|
||||
After importing the data, trigger the scanning process in the administrator's web UI: **Administration**->**Configuration**->**Vulnerability**->**SCAN NOW**. Harbor reflects the new changes after the scanning is completed. (Otherwise the summary of the image vulnerabilities will not be displayed correctly.)
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,646 +1,3 @@
|
||||
# Harbor Installation and Configuration Guide
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
There are two possibilities when installing Harbor.
|
||||
|
||||
- **Online installer:** The online installer downloads the Harbor images from Docker hub. For this reason, the installer is very small in size.
|
||||
|
||||
- **Offline installer:** Use the offline installer if the host to which are are deploying Harbor does not have a connection to the Internet. The offline installer contains pre-built images so it is larger than the online installer.
|
||||
|
||||
You download the installers from the **[official release](https://github.com/goharbor/harbor/releases)** page.
|
||||
|
||||
This guide describes how to install and configure Harbor by using either the online or offline installer. The installation processes are almost the same.
|
||||
|
||||
If you are upgrading from a previous version of Harbor, you might need to update the configuration file and migrate your data to fit the database schema of the later version. For information about upgrading, see the **[Harbor Upgrade and Migration Guide](migration_guide.md)**.
|
||||
|
||||
In addition, the Harbor community created instructions describing how to deploy Harbor on Kubernetes. If you want to deploy Harbor to Kubernetes, see [Harbor on Kubernetes](kubernetes_deployment.md).
|
||||
|
||||
## Harbor Components
|
||||
|
||||
The table below lists the components that are deployed when you deploy Harbor.
|
||||
|
||||
|Component|Version|
|
||||
|---|---|
|
||||
|Postgresql|9.6.10-1.ph2|
|
||||
|Redis|4.0.10-1.ph2|
|
||||
|Clair|2.0.8|
|
||||
|Beego|1.9.0|
|
||||
|Chartmuseum|0.9.0|
|
||||
|Docker/distribution|2.7.1|
|
||||
|Docker/notary|0.6.1|
|
||||
|Helm|2.9.1|
|
||||
|Swagger-ui|3.22.1|
|
||||
|
||||
## Deployment Prerequisites for the Target Host
|
||||
|
||||
Harbor is deployed as several Docker containers. You can therefore deploy it on any Linux distribution that supports Docker. The target host requires Docker, and Docker Compose to be installed.
|
||||
|
||||
### Hardware
|
||||
|
||||
The following table lists the minimum and recommended hardware configurations for deploying Harbor.
|
||||
|
||||
|Resource|Minimum|Recommended|
|
||||
|---|---|---|
|
||||
|CPU|2 CPU|4 CPU|
|
||||
|Mem|4 GB|8 GB|
|
||||
|Disk|40 GB|160 GB|
|
||||
|
||||
### Software
|
||||
|
||||
The following table lists the software versions that must be installed on the target host.
|
||||
|
||||
|Software|Version|Description|
|
||||
|---|---|---|
|
||||
|Docker engine|version 17.06.0-ce+ or higher|For installation instructions, see [docker engine doc](https://docs.docker.com/engine/installation/)|
|
||||
|Docker Compose|version 1.18.0 or higher|For installation instructions, see [docker compose doc](https://docs.docker.com/compose/install/)|
|
||||
|Openssl|latest is preferred|Used to generate certificate and keys for Harbor|
|
||||
|
||||
### Network ports
|
||||
|
||||
Harbor requires that the following ports be open on the target host.
|
||||
|
||||
|Port|Protocol|Description|
|
||||
|---|---|---|
|
||||
|443|HTTPS|Harbor portal and core API accept HTTPS requests on this port. You can change this port in the configuration file.|
|
||||
|4443|HTTPS|Connections to the Docker Content Trust service for Harbor. Only required if Notary is enabled. You can change this port in the configuration file.|
|
||||
|80|HTTP|Harbor portal and core API accept HTTP requests on this port. You can change this port in the configuration file.|
|
||||
|
||||
## Installation Procedure
|
||||
|
||||
The installation procedure involves the following steps:
|
||||
|
||||
1. Download the installer.
|
||||
2. Configure the **harbor.yml** file.
|
||||
3. Run the **install.sh** script with the appropriate options to install and start Harbor.
|
||||
|
||||
## Download and Unpack the Installer
|
||||
|
||||
1. Go to the [Harbor releases page](https://github.com/goharbor/harbor/releases).
|
||||
1. Download either the online or offline installer for the version you want to install.
|
||||
1. Optionally download the corresponding `*.asc` file to verify that the package is genuine.
|
||||
|
||||
The `*.asc` file is an OpenPGP key file. Perform the following steps to verify that the downloaded bundle is genuine.
|
||||
|
||||
1. Obtain the public key for the `*.asc` file.
|
||||
|
||||
<pre>gpg --keyserver hkps://keyserver.ubuntu.com --receive-keys 644FF454C0B4115C</pre>
|
||||
|
||||
You should see the message ` public key "Harbor-sign (The key for signing Harbor build) <jiangd@vmware.com>" imported`
|
||||
1. Verify that the package is genuine by running one of the following commands.
|
||||
|
||||
- Online installer: <pre>gpg -v --keyserver hkps://keyserver.ubuntu.com --verify harbor-online-installer-<i>version</i>.tgz.asc</pre>
|
||||
- Offline installer: <pre>gpg -v --keyserver hkps://keyserver.ubuntu.com --verify harbor-offline-installer-<i>version</i>.tgz.asc</pre>
|
||||
|
||||
The `gpg` command verifies that the signature of the bundle matches that of the `*.asc` key file. You should see confirmation that the signature is correct.
|
||||
|
||||
<pre>
|
||||
gpg: armor header: Version: GnuPG v1
|
||||
gpg: assuming signed data in 'harbor-offline-installer-v1.10.0-rc2.tgz'
|
||||
gpg: Signature made Fri, Dec 6, 2019 5:04:17 AM WEST
|
||||
gpg: using RSA key 644FF454C0B4115C
|
||||
gpg: using pgp trust model
|
||||
gpg: Good signature from "Harbor-sign (The key for signing Harbor build) <jiangd@vmware.com> [unknown]
|
||||
</pre>
|
||||
1. Use `tar` to extract the installer package:
|
||||
|
||||
- Online installer:<pre>bash $ tar xvf harbor-online-installer-<em>version</em>.tgz</pre>
|
||||
- Offline installer:<pre>bash $ tar xvf harbor-offline-installer-<em>version</em>.tgz</pre>
|
||||
|
||||
## Configure Harbor
|
||||
|
||||
You set system level parameters for Harbor in the `harbor.yml` file that is contained in the installer package. These parameters take effect when you run the `install.sh` script to install or reconfigure Harbor.
|
||||
|
||||
After the initial deployment and after you have started Harbor, you perform additional configuration in the Harbor Web Portal.
|
||||
|
||||
### Required Parameters
|
||||
|
||||
The table below lists the parameters that must be set when you deploy Harbor. By default, all of the required parameters are uncommented in the `harbor.yml` file. The optional parameters are commented with `#`. You do not necessarily need to change the values of the required parameters from the defaults that are provided, but these parameters must remain uncommented. At the very least, you must update the `hostname` parameter.
|
||||
|
||||
**IMPORTANT**: Harbor does not ship with any certificates. In versions up to and including 1.9.x, by default Harbor uses HTTP to serve registry requests. This is acceptable only in air-gapped test or development environments. In production environments, always use HTTPS. If you enable Content Trust with Notary to properly sign all images, you must use HTTPS.
|
||||
|
||||
You can use certificates that are signed by a trusted third-party CA, or you can use self-signed certificates. For information about how to create a CA, and how to use a CA to sign a server certificate and a client certificate, see **[Configuring Harbor with HTTPS Access](configure_https.md)**.
|
||||
|
||||
<table width="100%" border="0">
|
||||
<caption>
|
||||
Required Parameters for Harbor Deployment
|
||||
</caption>
|
||||
<tr>
|
||||
<th scope="col">Parameter</th>
|
||||
<th scope="col">Sub-parameters</th>
|
||||
<th scope="col">Description and Additional Parameters </th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>hostname</code></td>
|
||||
<td valign="top">None</td>
|
||||
<td valign="top">Specify the IP address or the fully qualified domain name (FQDN) of the target host on which to deploy Harbor. This is the address at which you access the Harbor Portal and the registry service. For example, <code>192.168.1.10</code> or <code>reg.yourdomain.com</code>. The registry service must be accessible to external clients, so do not specify <code>localhost</code>, <code>127.0.0.1</code>, or <code>0.0.0.0</code> as the hostname.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>https</code></td>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><p>Use HTTPS to access the Harbor Portal and the token/notification service. Always use HTTPS in production environments and environments that are not air-gapped.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>port</code></td>
|
||||
<td valign="top">The port number for HTTPS. The default is 443.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>certificate</code></td>
|
||||
<td valign="top">The path to the SSL certificate.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>private_key</code></td>
|
||||
<td valign="top">The path to the SSL key.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>harbor_admin_password</code></td>
|
||||
<td valign="top">None</td>
|
||||
<td valign="top">Set an initial password for the Harbor system administrator. This password is only used on the first time that Harbor starts. On subsequent logins, this setting is ignored and the administrator's password is set in the Harbor Portal. The default username and password are <code>admin</code> and <code>Harbor12345</code>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>database</code></td>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top">Use a local PostgreSQL database. You can optionally configure an external database, in which case you can disable this option.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>password</code></td>
|
||||
<td valign="top">Set the root password for the local database. You must change this password for production deployments.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>max_idle_conns</code></td>
|
||||
<td valign="top">The maximum number of connections in the idle connection pool. If set to <=0 no idle connections are retained. The default value is 50. If it is not configured the value is 2.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>max_open_conns</code></td>
|
||||
<td valign="top">The maximum number of open connections to the database. If <= 0 there is no limit on the number of open connections. The default value is 100 for the max connections to the Harbor database. If it is not configured the value is 0.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>data_volume</code></td>
|
||||
<td valign="top">None</td>
|
||||
<td valign="top">The location on the target host in which to store Harbor's data. You can optionally configure external storage, in which case disable this option and enable <code>storage_service</code>. The default is <code>/data</code>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>clair</code></td>
|
||||
<td valign="top"><code>updaters_interval</code></td>
|
||||
<td valign="top">Set an interval for Clair updates, in hours. Set to 0 to disable the updates. The default is 12 hours.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>jobservice</code></td>
|
||||
<td valign="top"><code>max_job_workers</code></td>
|
||||
<td valign="top">The maximum number of replication workers in the job service. For each image replication job, a worker synchronizes all tags of a repository to the remote destination. Increasing this number allows more concurrent replication jobs in the system. However, since each worker consumes a certain amount of network/CPU/IO resources, set the value of this attribute based on the hardware resource of the host. The default is 10.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>notification</code></td>
|
||||
<td valign="top"><code>webhook_job_max_retry</code></td>
|
||||
<td valign="top">Set the maximum number of retries for web hook jobs. The default is 10.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>chart</code></td>
|
||||
<td valign="top"><code>absolute_url</code></td>
|
||||
<td valign="top">Set to <code>enabled</code> for Chart to use an absolute URL. Set to <code>disabled</code> for Chart to use a relative URL.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>log</code></td>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top">Configure logging.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>level</code></td>
|
||||
<td valign="top">Set the logging level to <code>debug</code>, <code>info</code>, <code>warning</code>, <code>error</code>, or <code>fatal</code>. The default is <code>info</code>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>local</code></td>
|
||||
<td valign="top">Set the log retention parameters:<ul>
|
||||
<li><code>rotate_count</code>: Log files are rotated <code>rotate_count</code> times before being removed. If count is 0, old versions are removed rather than rotated. The default is 50.</li>
|
||||
<li><code>rotate_size</code>: Log files are rotated only if they grow bigger than <code>rotate_size</code> bytes. Use <code>k</code> for kilobytes, <code>M</code> for megabytes, and <code>G</code> for gigabytes. <code>100</code>, <code>100k</code>, <code>100M</code> and <code>100G</code> are all valid values. The default is 200M.</li>
|
||||
<li><code>location</code>: Set the directory in which to store the logs. The default is <code>/var/log/harbor</code>.</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>external_endpoint</code></td>
|
||||
<td valign="top">Enable this option to forward logs to a syslog server.
|
||||
<ul>
|
||||
<li><code>protocol</code>: Transport protocol for the syslog server. Default is TCP.</li>
|
||||
<li><code>host</code>: The URL of the syslog server.</li>
|
||||
<li><code>port</code>: The port on which the syslog server listens</li>
|
||||
</ul> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>proxy</code></td>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top">Configure proxies to be used by Clair, the replication jobservice, and Harbor. Leave blank if no proxies are required.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>http_proxy</code></td>
|
||||
<td valign="top">Configure an HTTP proxy, for example, <code>http://my.proxy.com:3128</code>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>https_proxy</code></td>
|
||||
<td valign="top">Configure an HTTPS proxy, for example, <code>http://my.proxy.com:3128</code>.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>no_proxy</code></td>
|
||||
<td valign="top">Configure when not to use a proxy, for example, <code>127.0.0.1,localhost,core,registry</code>.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Optional parameters
|
||||
|
||||
The following table lists the additional, optional parameters that you can set to configure your Harbor deployment beyond the minimum required settings. To enable a setting, you must uncomment it in `harbor.yml` by deleting the leading `#` character.
|
||||
|
||||
<table width="100%" border="0">
|
||||
<caption>
|
||||
Optional Parameters for Harbor
|
||||
</caption>
|
||||
<tr>
|
||||
<th scope="col">Parameter</th>
|
||||
<th scope="col">Sub-Parameters</th>
|
||||
<th scope="col">Description and Additional Parameters </th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>http</code></td>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top">Do not use HTTP in production environments. Using HTTP is acceptable only in air-gapped test or development environments that do not have a connection to the external internet. Using HTTP in environments that are not air-gapped exposes you to man-in-the-middle attacks.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>port</code></td>
|
||||
<td valign="top">Port number for HTTP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>external_url</code></td>
|
||||
<td valign="top">None</td>
|
||||
<td valign="top">Enable this option to use an external proxy. When enabled, the hostname is no longer used.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<tr>
|
||||
<td valign="top"><code>storage_service</code></td>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top">By default, Harbor stores images and charts on your local filesystem. In a production environment, you might want to use another storage backend instead of the local filesystem. The parameters listed below are the configurations for the registry. See *Configuring Storage Backend* below for more information about how to configure a different backend.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>ca_bundle</code></td>
|
||||
<td valign="top">The path to the custom root CA certificate, which is injected into the trust store of registry and chart repository containers. This is usually needed if internal storage uses a self signed certificate.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>filesystem</code></td>
|
||||
<td valign="top">The default is <code>filesystem</code>, but you can set <code>azure</code>, <code>gcs</code>, <code>s3</code>, <code>swift</code> and <code>oss</code>. For information about how to configure other backends, see <a href="#backend">Configuring a Storage Backend</a> below. Set <code>maxthreads</code> to limit the number of threads to the external provider. The default is 100.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>redirect</code></td>
|
||||
<td valign="top">Set <code>disable</code> to <code>true</code> when you want to disable registry redirect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>external_database</code></td>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top">Configure external database settings, if you disable the local database option. Harbor currently only supports POSTGRES.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>harbor</code></td>
|
||||
<td valign="top"><p>Configure an external database for Harbor data.</p>
|
||||
<ul>
|
||||
<li><code>host</code>: Hostname of the Harbor database.</li>
|
||||
<li><code>port</code>: Database port.</li>
|
||||
<li><code>db_name</code>: Database name.</li>
|
||||
<li><code>username</code>: Username to connect to the core Harbor database.</li>
|
||||
<li><code>password</code>: Password for the account you set in <code>username</code>.</li>
|
||||
<li><code>ssl_mode</code>: Enable SSL mode.</li>
|
||||
<li><code>max_idle_conns</code>: The maximum number of connections in the idle connection pool. If <=0 no idle connections are retained. The default value is 2.</li>
|
||||
<li><code>max_open_conns</code>: The maximum number of open connections to the database. If <= 0 there is no limit on the number of open connections. The default value is 0.</li>
|
||||
</ul> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>clair</code></td>
|
||||
<td valign="top">Configure an external database for Clair.
|
||||
<ul>
|
||||
<li><code>host</code>: Hostname of the Clair database</li>
|
||||
<li><code>port</code>: Database port.</li>
|
||||
<li><code>db_name</code>: Database name.</li>
|
||||
<li><code>username</code>: Username to connect to the Clair database.</li>
|
||||
<li><code>password</code>: Password for the account you set in <code>username</code>.</li>
|
||||
<li><code>ssl_mode</code>: Enable SSL mode.</li>
|
||||
</ul> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>notary_signer</code></td>
|
||||
<td valign="top">Configure an external database for the Notary signer database
|
||||
<ul>
|
||||
<li><code>host</code>: Hostname of the Notary signer database</li>
|
||||
<li><code>port</code>: Database port.</li>
|
||||
<li><code>db_name</code>: Database name.</li>
|
||||
<li><code>username</code>: Username to connect to the Notary signer database.</li>
|
||||
<li><code>password</code>: Password for the account you set in <code>username</code>.</li>
|
||||
<li><code>ssl_mode</code>: Enable SSL mode.</li>
|
||||
</ul> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>notary_server</code></td>
|
||||
<td valign="top"><ul>
|
||||
<li><code>host</code>: Hostname of the Notary server database.</li>
|
||||
<li><code>port</code>: Database port.</li>
|
||||
<li><code>db_name</code>: Database name.</li>
|
||||
<li><code>username</code>: Username to connect to the Notary server database.</li>
|
||||
<li><code>password</code>: Password for the account you set in <code>username</code>.</li>
|
||||
<li><code>ssl_mode</code>: Enable SSL mode.e</li>
|
||||
</ul> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"><code>external_redis</code></td>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top">Configure an external Redis instance.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>host</code></td>
|
||||
<td valign="top">Hostname of the external Redis instance.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>port</code></td>
|
||||
<td valign="top">Redis instance port.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>password</code></td>
|
||||
<td valign="top">Password to connect to the external Redis instance.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>registry_db_index</code></td>
|
||||
<td valign="top">Database index for Harbor registry.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>jobservice_db_index</code></td>
|
||||
<td valign="top">Database index for jobservice.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top"> </td>
|
||||
<td valign="top"><code>chartmuseum_db_index</code></td>
|
||||
<td valign="top">Database index for Chart museum.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
**NOTE**: The `harbor.yml` file includes options to configure a UAA CA certificate. This authentication mode is not recommended and is not documented.
|
||||
|
||||
<a id="backend"></a>
|
||||
### Configuring a Storage Backend
|
||||
|
||||
By default Harbor uses local storage for the registry, but you can optionally configure the `storage_service` setting so that Harbor uses external storage. For information about how to configure the storage backend of a registry for different storage providers, see the [Registry Configuration Reference](https://docs.docker.com/registry/configuration/#storage) in the Docker documentation. For example, if you use Openstack Swift as your storage backend, the parameters might resemble the following:
|
||||
|
||||
``` yaml
|
||||
storage_service:
|
||||
ca_bundle:
|
||||
swift:
|
||||
username: admin
|
||||
password: ADMIN_PASS
|
||||
authurl: http://keystone_addr:35357/v3/auth
|
||||
tenant: admin
|
||||
domain: default
|
||||
region: regionOne
|
||||
container: docker_images"
|
||||
redirect:
|
||||
disable: false
|
||||
```
|
||||
|
||||
|
||||
## Installing and starting Harbor
|
||||
|
||||
Once you have configured **harbor.yml** optionally set up a storage backend, you install and start Harbor by using the `install.sh` script. Note that it might take some time for the online installer to download all of the `Harbor images from Docker hub.
|
||||
|
||||
You can install Harbor in different configurations:
|
||||
|
||||
- Just Harbor, without Notary, Clair, or Chart Repository Service
|
||||
- Harbor with Notary
|
||||
- Harbor with Clair
|
||||
- Harbor with Chart Repository Service
|
||||
- Harbor with two or all three of Notary, Clair, and Chart Repository Service
|
||||
|
||||
### Default installation without Notary, Clair, or Chart Repository Service
|
||||
|
||||
The default Harbor installation does not include Notary or Clair service.
|
||||
|
||||
``` sh
|
||||
$ sudo ./install.sh
|
||||
```
|
||||
|
||||
If the installation succeeds, you can open a browser to visit the Harbor Portal at `http://reg.yourdomain.com`, changing `reg.yourdomain.com` to the hostname that you configured in `harbor.yml`. If you did not change them, the default administrator username and password are `admin` and `Harbor12345`.
|
||||
|
||||
Log in to the admin portal and create a new project, for example, `myproject`. You can then use docker commands to log in and push images to Harbor. By default, the registry server listens on port 80:
|
||||
|
||||
```sh
|
||||
$ docker login reg.yourdomain.com
|
||||
$ docker push reg.yourdomain.com/myproject/myrepo:mytag
|
||||
```
|
||||
|
||||
### Installation with Notary
|
||||
|
||||
To install Harbor with the Notary service, add the `--with-notary` parameter when you run `install.sh`:
|
||||
|
||||
```sh
|
||||
$ sudo ./install.sh --with-notary
|
||||
```
|
||||
|
||||
**Note**: For installation with Notary, you must use Harbor with HTTPS.
|
||||
|
||||
For more information about Notary and Docker Content Trust, see [Content Trust](https://docs.docker.com/engine/security/trust/content_trust/) in the Docker documentation.
|
||||
|
||||
### Installation with Clair
|
||||
|
||||
To install Harbor with Clair service, add the `--with-clair` parameter when you run `install.sh`:
|
||||
|
||||
```sh
|
||||
$ sudo ./install.sh --with-clair
|
||||
```
|
||||
|
||||
For more information about Clair, see the [Clair documentation](https://coreos.com/clair/docs/2.0.1/).
|
||||
|
||||
### Installation with Chart Repository Service
|
||||
|
||||
To install Harbor with chart repository service, add the `--with-chartmuseum` parameter when you run ```install.sh```:
|
||||
|
||||
```sh
|
||||
$ sudo ./install.sh --with-chartmuseum
|
||||
```
|
||||
|
||||
### Installation with Notary, Clair, and Chart Repository Service
|
||||
|
||||
If you want to install all three of Notary, Clair and chart repository service, you must specify all of the parameters in the same command:
|
||||
|
||||
```sh
|
||||
$ sudo ./install.sh --with-notary --with-clair --with-chartmuseum
|
||||
```
|
||||
|
||||
<a id="connect_http"></a>
|
||||
## Connecting to Harbor via HTTP
|
||||
|
||||
**IMPORTANT:** If your installation of Harbor uses HTTP rather than HTTPS, you must add the option `--insecure-registry` to your client's Docker daemon. By default, the daemon file is located at `/etc/docker/daemon.json`.
|
||||
|
||||
For example, add the following to your `daemon.json` file:
|
||||
|
||||
<pre>
|
||||
{
|
||||
"insecure-registries" : ["<i>myregistrydomain.com</i>:5000", "0.0.0.0"]
|
||||
}
|
||||
</pre>
|
||||
|
||||
After you update `daemon.json`, you must restart both Docker Engine and Harbor.
|
||||
|
||||
1. Restart Docker Engine.
|
||||
|
||||
`systemctl restart docker`
|
||||
1. Stop Harbor.
|
||||
|
||||
`docker-compose down -v`
|
||||
1. Restart Harbor.
|
||||
|
||||
`docker-compose up -d`
|
||||
|
||||
## Using Harbor
|
||||
|
||||
For information on how to use Harbor, see the **[Harbor User Guide](user_guide.md)** .
|
||||
|
||||
## Managing Harbor Lifecycle
|
||||
|
||||
You can use `docker-compose` to manage the lifecycle of Harbor. Some useful commands are listed below. You must run the commands in the same directory as `docker-compose.yml`.
|
||||
|
||||
### Stop Harbor:
|
||||
|
||||
``` sh
|
||||
$ sudo docker-compose stop
|
||||
Stopping nginx ... done
|
||||
Stopping harbor-portal ... done
|
||||
Stopping harbor-jobservice ... done
|
||||
Stopping harbor-core ... done
|
||||
Stopping registry ... done
|
||||
Stopping redis ... done
|
||||
Stopping registryctl ... done
|
||||
Stopping harbor-db ... done
|
||||
Stopping harbor-log ... done
|
||||
```
|
||||
|
||||
### Restart Harbor after Stopping:
|
||||
|
||||
``` sh
|
||||
$ sudo docker-compose start
|
||||
Starting log ... done
|
||||
Starting registry ... done
|
||||
Starting registryctl ... done
|
||||
Starting postgresql ... done
|
||||
Starting core ... done
|
||||
Starting portal ... done
|
||||
Starting redis ... done
|
||||
Starting jobservice ... done
|
||||
Starting proxy ... done
|
||||
```
|
||||
|
||||
### Reconfigure Harbor
|
||||
|
||||
To reconfigure Harbor, stop the existing Harbor instance and update `harbor.yml`. Then run `prepare` script to populate the configuration. Finally re-create and start the Harbor instance.
|
||||
|
||||
``` sh
|
||||
$ sudo docker-compose down -v
|
||||
$ vim harbor.yml
|
||||
$ sudo prepare
|
||||
$ sudo docker-compose up -d
|
||||
```
|
||||
|
||||
### Other Commands
|
||||
|
||||
Remove Harbor's containers while keeping the image data and Harbor's database files on the file system:
|
||||
|
||||
``` sh
|
||||
$ sudo docker-compose down -v
|
||||
```
|
||||
|
||||
Remove Harbor's database and image data for a clean re-installation:
|
||||
|
||||
``` sh
|
||||
$ rm -r /data/database
|
||||
$ rm -r /data/registry
|
||||
```
|
||||
|
||||
### Managing the Harbor Lifecycle with Notary, Clair and Chart Repository Service
|
||||
|
||||
If you want to install Notary, Clair and chart repository service together, you should include all the components in the prepare commands:
|
||||
|
||||
``` sh
|
||||
$ sudo docker-compose down -v
|
||||
$ vim harbor.yml
|
||||
$ sudo prepare --with-notary --with-clair --with-chartmuseum
|
||||
$ sudo docker-compose up -d
|
||||
```
|
||||
|
||||
Please check the [Docker Compose command-line reference](https://docs.docker.com/compose/reference/) for more on docker-compose.
|
||||
|
||||
## Persistent Data and Log Files
|
||||
|
||||
By default, registry data is persisted in the host's `/data/` directory. This data remains unchanged even when Harbor's containers are removed and/or recreated. You can edit the `data_volume` in `harbor.yml` file to change this directory.
|
||||
|
||||
In addition, Harbor uses `rsyslog` to collect the logs for each container. By default, these log files are stored in the directory `/var/log/harbor/` on the target host. You can change the log directory in `harbor.yml`.
|
||||
|
||||
## Configuring Harbor to Listen on a Customized Port
|
||||
|
||||
By default, Harbor listens on port 443(HTTPS) and 80(HTTP, if configured) for both Harbor portal and Docker commands. You can reconfigure the default ports in `harbor.yml`
|
||||
|
||||
## Configure Harbor with an External Database
|
||||
|
||||
Currently, Harbor only supports PostgreSQL database. To user an external database, uncomment the `external_database` section in `harbor.yml` and fill the necessary information. You must create four databases for Harbor core, Clair, Notary server, and Notary signer. And the tables are generated automatically when Harbor starts up.
|
||||
|
||||
## Manage User Settings
|
||||
|
||||
User settings are handled separately system settings. All user settings are configured in the Harbor portal or by HTTP requests at the command line. For information about using HTTP requests to configure user settings, see [Configure User Settings at the Command Line](configure_user_settings.md) to config user settings.
|
||||
|
||||
## Performance Tuning
|
||||
|
||||
By default, Harbor limits the CPU usage of the Clair container to 150000 to avoid it using up all CPU resources. This is defined in the `docker-compose.clair.yml` file. You can modify this file based on your hardware configuration.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Harbor Doesn't Start or Functions Incorrectly
|
||||
|
||||
When Harbor does not function correctly, run the following commands to find out if all of Harbor's containers in **UP** status:
|
||||
```
|
||||
$ sudo docker-compose ps
|
||||
Name Command State Ports
|
||||
-----------------------------------------------------------------------------------------------------------------------------
|
||||
harbor-core /harbor/start.sh Up
|
||||
harbor-db /entrypoint.sh postgres Up 5432/tcp
|
||||
harbor-jobservice /harbor/start.sh Up
|
||||
harbor-log /bin/sh -c /usr/local/bin/ ... Up 127.0.0.1:1514->10514/tcp
|
||||
harbor-portal nginx -g daemon off; Up 80/tcp
|
||||
nginx nginx -g daemon off; Up 0.0.0.0:443->443/tcp, 0.0.0.0:4443->4443/tcp, 0.0.0.0:80->80/tcp
|
||||
redis docker-entrypoint.sh redis ... Up 6379/tcp
|
||||
registry /entrypoint.sh /etc/regist ... Up 5000/tcp
|
||||
registryctl /harbor/start.sh Up
|
||||
```
|
||||
|
||||
If a container is not in the `Up` state, check the log file for that container in `/var/log/harbor`. For example, if the `harbor-core` container is not running, look at the `core.log` log file.
|
||||
|
||||
### Using nginx or Load Balancing
|
||||
|
||||
When setting up Harbor behind an `nginx` proxy or elastic load balancing, look for the following line in `common/config/nginx/nginx.conf` and, if the proxy already has similar settings, remove it from the sections `location /`, `location /v2/` and `location /service/`.
|
||||
|
||||
``` sh
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
```
|
||||
|
||||
Then re-deploy Harbor per the instructions in "Managing Harbor Lifecycle.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,4 +1,4 @@
|
||||
Please use [Harbor Helm Chart](https://github.com/goharbor/harbor-helm) to deploy latest Harbor release on Kubernetes.
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
**NOTE** Please open issue to the `harbor-helm` repo if you see issues deploying the helm chart.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
|
||||
|
||||
@ -1,12 +1,3 @@
|
||||
## Introduction
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
You can import an LDAP/AD group to Harbor and assign project roles to it. All LDAP/AD users in this LDAP/AD group have assigned roles.
|
||||
|
||||
**NOTE**: Information about how to configure LDAP Groups in the Harbor interface has migrated to the [Harbor User Guide](user_guide.md).
|
||||
|
||||
To configure LDAP parameters via the API, see **[Configure Harbor User Settings from the Command Line](configure_user_settings.md)**
|
||||
|
||||
For example:
|
||||
```
|
||||
curl -X PUT -u "<username>:<password>" -H "Content-Type: application/json" -ki https://harbor.sample.domain/api/configurations -d'{"ldap_group_basedn":"ou=groups,dc=example,dc=com"}'
|
||||
```
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,106 +1,3 @@
|
||||
# Harbor Upgrade and Migration Guide
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
This guide covers upgrade and migration to version 1.9.0. This guide only covers migration from v1.7.x and later to the current version. If you are upgrading from an earlier version, refer to the migration guide in the `release-1.7.0` branch to upgrade to v1.7.x first, then follow this guide to perform the migration to this version.
|
||||
|
||||
When upgrading an existing Harbor 1.7.x instance to a newer version, you might need to migrate the data in your database and the settings in `harbor.cfg`.
|
||||
Since the migration might alter the database schema and the settings of `harbor.cfg`, you should **always** back up your data before any migration.
|
||||
|
||||
**NOTES:**
|
||||
|
||||
- Again, you must back up your data before any data migration.
|
||||
- Since v1.8.0, the configuration of Harbor has changed to a `.yml` file. If you are upgrading from 1.7.x, the migrator will transform the configuration file from `harbor.cfg` to `harbor.yml`. The command will be a little different to perform this migration, so make sure you follow the steps below.
|
||||
- In version 1.9.0, some containers are started by `non-root`. This does not pose problems if you are upgrading an officially released version of Harbor, but if you have deployed a customized instance of Harbor, you might encounter permission issues.
|
||||
- In previous releases, user roles took precedence over group roles in a project. In this version, user roles and group roles are combined so that the user has whichever set of permissions is highest. This might cause the roles of certain users to change during upgrade.
|
||||
- With the introduction of storage and artifact quotas in version 1.9.0, migration from 1.7.x and 1.8.x might take a few minutes. This is because the `core` walks through all blobs in the registry and populates the database with information about the layers and artifacts in projects.
|
||||
- With the introduction of storage and artifact quotas in version 1.9.0, replication between version 1.9.0 and a previous version of Harbor does not work. You must upgrade all Harbor nodes to 1.9.0 if you have configured replication between them.
|
||||
|
||||
## Upgrading Harbor and Migrating Data
|
||||
|
||||
1. Log in to the host that Harbor runs on, stop and remove existing Harbor instance if it is still running:
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
docker-compose down
|
||||
```
|
||||
|
||||
2. Back up Harbor's current files so that you can roll back to the current version if necessary.
|
||||
|
||||
```sh
|
||||
mv harbor /my_backup_dir/harbor
|
||||
```
|
||||
|
||||
Back up database (by default in directory `/data/database`)
|
||||
|
||||
```sh
|
||||
cp -r /data/database /my_backup_dir/
|
||||
```
|
||||
|
||||
3. Get the latest Harbor release package from Github:
|
||||
[https://github.com/goharbor/harbor/releases](https://github.com/goharbor/harbor/releases)
|
||||
|
||||
4. Before upgrading Harbor, perform migration first. The migration tool is delivered as a docker image.
|
||||
|
||||
You can pull the image from docker hub. Replace [tag] with the release version of Harbor (e.g. v1.5.0) in the below command:
|
||||
```sh
|
||||
docker pull goharbor/harbor-migrator:[tag]
|
||||
```
|
||||
|
||||
Alternatively, if you are using an offline installer package you can load it from the image tarball included in the offline installer package. Replace [version] with the release version of Harbor (e.g. v1.5.0) in the below command:
|
||||
```sh
|
||||
tar zxf <offline package>
|
||||
docker image load -i harbor/harbor.[version].tar.gz
|
||||
```
|
||||
|
||||
5. If you are current version is v1.7.x or earlier, i.e. migrate config file from `harbor.cfg` to `harbor.yml`.
|
||||
|
||||
**NOTE:** You can find the ${harbor_yml} in the extracted installer you got in step `3`, after the migration the file `harbor.yml`
|
||||
in that path will be updated with the values from ${harbor_cfg}
|
||||
|
||||
```sh
|
||||
docker run -it --rm -v ${harbor_cfg}:/harbor-migration/harbor-cfg/harbor.yml -v ${harbor_yml}:/harbor-migration/harbor-cfg-out/harbor.yml goharbor/harbor-migrator:[tag] --cfg up
|
||||
```
|
||||
|
||||
Otherwise, If your version is 1.8.x or higher, just upgrade the `harbor.yml` file.
|
||||
|
||||
```sh
|
||||
docker run -it --rm -v ${harbor_yml}:/harbor-migration/harbor-cfg/harbor.yml goharbor/harbor-migrator:[tag] --cfg up
|
||||
```
|
||||
|
||||
**NOTE:** The schema upgrade and data migration of the database is performed by core when Harbor starts, if the migration fails, please check the log of core to debug.
|
||||
|
||||
6. Under the directory `./harbor`, run the `./install.sh` script to install the new Harbor instance. If you choose to install Harbor with components such as Notary, Clair, and chartmuseum, refer to [Installation & Configuration Guide](../docs/installation_guide.md) for more information.
|
||||
|
||||
## Roll Back from an Upgrade
|
||||
|
||||
If, for any reason, you want to roll back to the previous version of Harbor, perform the following steps:
|
||||
|
||||
1. Stop and remove the current Harbor service if it is still running.
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
docker-compose down
|
||||
```
|
||||
|
||||
2. Remove current Harbor instance.
|
||||
|
||||
```sh
|
||||
rm -rf harbor
|
||||
```
|
||||
|
||||
3. Restore the older version package of Harbor.
|
||||
|
||||
```sh
|
||||
mv /my_backup_dir/harbor harbor
|
||||
```
|
||||
|
||||
4. Restore database, copy the data files from backup directory to you data volume, by default `/data/database`.
|
||||
|
||||
5. Restart Harbor service using the previous configuration.
|
||||
If previous version of Harbor was installed by a release build:
|
||||
|
||||
```sh
|
||||
cd harbor
|
||||
./install.sh
|
||||
```
|
||||
|
||||
**NOTE**: While you can roll back an upgrade to the state before you started the upgrade, Harbor does not support downgrades.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,58 +1,3 @@
|
||||
# Permissions
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
Users have different abilities depending on the role they in a project.
|
||||
|
||||
On public projects all users will be able to see the list of repositories, images, image vulnerabilities, helm charts and helm chart versions, pull images, retag images (need push permission for destination image), download helm charts, download helm chart versions.
|
||||
|
||||
System admin have all permissions for the project.
|
||||
|
||||
## Project members permissions
|
||||
|
||||
The following table depicts the various user permission levels in a project.
|
||||
|
||||
| Action | Limited Guest | Guest | Developer | Master | Project Admin |
|
||||
| --------------------------------------- | ------------- | ----- | --------- | ------ | ------------- |
|
||||
| See the project configurations | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Edit the project configurations | | | | | ✓ |
|
||||
| See a list of project members | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create/edit/delete project members | | | | | ✓ |
|
||||
| See a list of project logs | | ✓ | ✓ | ✓ | ✓ |
|
||||
| See a list of project replications | | | | ✓ | ✓ |
|
||||
| See a list of project replication jobs | | | | | ✓ |
|
||||
| See a list of project labels | | | | ✓ | ✓ |
|
||||
| Create/edit/delete project labels | | | | ✓ | ✓ |
|
||||
| See a list of repositories | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create repositories | | | ✓ | ✓ | ✓ |
|
||||
| Edit/delete repositories | | | | ✓ | ✓ |
|
||||
| See a list of images | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Retag image | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Pull image | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Push image | | | ✓ | ✓ | ✓ |
|
||||
| Scan/delete image | | | | ✓ | ✓ |
|
||||
| Add scanners to Harbor | | | | | |
|
||||
| Edit scanners in projects | | | | | ✓ |
|
||||
| See a list of image vulnerabilities | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| See image build history | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Add/Remove labels of image | | | ✓ | ✓ | ✓ |
|
||||
| See a list of helm charts | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Download helm charts | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Upload helm charts | | | ✓ | ✓ | ✓ |
|
||||
| Delete helm charts | | | | ✓ | ✓ |
|
||||
| See a list of helm chart versions | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Download helm chart versions | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Upload helm chart versions | | | ✓ | ✓ | ✓ |
|
||||
| Delete helm chart versions | | | | ✓ | ✓ |
|
||||
| Add/Remove labels of helm chart version | | | ✓ | ✓ | ✓ |
|
||||
| See a list of project robots | | | | ✓ | ✓ |
|
||||
| Create/edit/delete project robots | | | | | ✓ |
|
||||
| See configured CVE whitelist | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Create/edit/remove CVE whitelist | | | | | ✓ |
|
||||
| Enable/disable webhooks | | | ✓ | ✓ | ✓ |
|
||||
| Create/delete tag retention rules | | | ✓ | ✓ | ✓ |
|
||||
| Enable/disable tag retention rules | | | ✓ | ✓ | ✓ |
|
||||
| Create/delete tag immutability rules | | | | | ✓ |
|
||||
| Enable/disable tag immutability rules | | | | | ✓ |
|
||||
| See project quotas | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
| Edit project quotas * | | | | | |
|
||||
|
||||
* Only the Harbor system administrator can edit project quotas and add new scanners.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,32 +1,3 @@
|
||||
# Registry Landscape
|
||||
The cloud native ecosystem is moving rapidly–registries and their feature sets are no exception. We've made our best effort to survey the container registry landscape and compare to our core feature set.
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
If you find something outdated or outright erroneous, please submit a PR and we'll fix it right away.
|
||||
|
||||
Table updated on 10/21/2019 against Harbor 1.9.
|
||||
|
||||
| Feature | Harbor | Docker Trusted Registry | Quay | Cloud Providers (GCP, AWS, Azure) | Docker Distribution | Artifactory | GitLab |
|
||||
| -------------: | :----: | :---------------------: | :-----: | :-------------------------------: | :-----------------: | :---------: | :------: |
|
||||
| Ability to Determine Version of Binaries in Containers | ✓ | ✓ | ✓ | ✗ | ✗ | ? | ? |
|
||||
| Artifact Repository (rpms, git, jar, etc) | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | partial |
|
||||
| Audit Logs | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ |
|
||||
| Content Trust and Validation | ✓ | ✓ | ✗ | ✗ | partial | partial | ✗ |
|
||||
| Custom TLS Certificates | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ |
|
||||
| Helm Chart Repository Manager | ✓ | ✗ | partial | ✗ | ✗ | ✓ | ✗ |
|
||||
| LDAP-based Auth | ✓ | ✓ | ✓ | partial | ✗ | ✓ | ✓ |
|
||||
| Local Auth | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✓ |
|
||||
| Multi-Tenancy (projects, teams, namespaces, etc) | ✓ | ✓ | ✓ | partial | ✗ | ✓ | ✓ |
|
||||
| Open Source | ✓ | partial | ✗ | ✗ | ✓ | partial | partial |
|
||||
| Project Quotas (by image count & storage consumption) | ✓ | ✗ | ✗ | partial | ✗ | ✗ | ✗ |
|
||||
| Replication between instances | ✓ | ✓ | ✓ | n/a | ✗ | ✓ | ✗ |
|
||||
| Replication between non-instances | ✓ | ✗ | ✓ | n/a | ✗ | ✗ | ✗ |
|
||||
| Robot Accounts for Helm Charts | ✓ | ✗ | ✗ | ? | ✗ | ✗ | ✗ |
|
||||
| Robot Accounts for Images | ✓ | ? | ✓ | ? | ✗ | ? | ? |
|
||||
| Role-Based Access Control | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | ✗ |
|
||||
| Single Sign On (OIDC) | ✓ | ✓ | ✓ | ✓ | ✗ | partial | ✗ |
|
||||
| Tag Retention Policy | ✓ | ✗ | partial | ✗ | ✗ | ✗ | ✗ |
|
||||
| Upstream Registry Proxy Cache | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✗ |
|
||||
| Vulnerability Scanning & Monitoring | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | partial |
|
||||
| Vulnerability Scanning Plugin Framework | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
|
||||
| Vulnerability Whitelisting | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
|
||||
| Webhooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,94 +1,3 @@
|
||||
# Harbor frontend environment get started guide
|
||||
|
||||
If you already have a harbor backend environment, you can build a frontend development environment with the following configuration.
|
||||
|
||||
1. Create the file proxy.config.json in the directory harbor/src/portal，and config it according to the sample below.
|
||||
|
||||
**NOTE:** You should replace “$IP_ADDRESS” with your own ip address.
|
||||
|
||||
```
|
||||
{
|
||||
"/api/*": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"changeOrigin": true,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/service/*": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/c/login": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/sign_in": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/c/log_out": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/sendEmail": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/language": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/reset": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/userExists": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/reset_password": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/i18n/lang/*.json": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug",
|
||||
"pathRewrite": { "^/src$": "" }
|
||||
},
|
||||
"/chartrepo": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
},
|
||||
"/*.json": {
|
||||
"target": "$IP_ADDRESS",
|
||||
"secure": false,
|
||||
"logLevel": "debug"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. Open the terminal and run the following command，install npm packages as 3rd-party dependencies.
|
||||
```
|
||||
cd harbor/src/portal
|
||||
npm install
|
||||
```
|
||||
|
||||
3. Execute the following command，serve Harbor locally.
|
||||
|
||||
```
|
||||
npm run start
|
||||
```
|
||||
|
||||
4. Then you can visit the Harbor by address: https://localhost:4200.
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,44 +1,3 @@
|
||||
This guide is for Harbor upgrade test
|
||||
=======
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
# Before upgrade
|
||||
|
||||
## Prepare data
|
||||
1. Add user usera userb userc userd usere, set usera userb as system admin.
|
||||
2. Create project projecta projectc as private, create projectb as public.
|
||||
3. Add usera as projecta's admin, userc as developer, and userd as guest. Do the same to projectb and projectc.
|
||||
4. Login harbor as usera, push an unsigned image into projecta, then push a signed image to projecta.
|
||||
5. Login harbor as userc, push an unsigned image into projecta, then push a signed image to projeca.
|
||||
6. Login harbor as userd, push each image one time.
|
||||
7. Repeat 4 5 6 to projectb and projectc.
|
||||
8. Add one endpoint to harbor.
|
||||
9. Add an immediate replication rule to projeca, a schedule rule to projectb, a manual rule to projectc, trigger each rule one time.
|
||||
10. Add 5 system label syslabel1 to syslabel5 and tag syslabel1 and syslabel2 to all unsigned image.
|
||||
11. In each project add 5 project label projlabela to projlabele, add projlabela projlabelb and projlabelc to signed image.
|
||||
12. Trigger one scan all job to scan all images.(For clair enabled instance)
|
||||
13. Update project publicly, content trust, severity and scanning settings.
|
||||
14. Update Harbor email, token expire read only and scan settings.
|
||||
15. Update repository info.
|
||||
**NOTE**: Create user step is not needed if auth mode is LDAP.
|
||||
|
||||
# Upgrade
|
||||
|
||||
## Follow the upgrade guide
|
||||
1. Run db migrator image to backup database.
|
||||
2. Run db migrator image to migrate database.
|
||||
3. Install new version harbor.
|
||||
|
||||
# After upgrade
|
||||
|
||||
1. Confirm users are exist and available(No need for VIC and LDAP Mode).
|
||||
2. Confirm users have the correct role.
|
||||
3. Confirm labels are existing and labeled correct.(No need for VIC)
|
||||
4. Confirm notary signature correct.
|
||||
5. Confirm endpoint exist.
|
||||
6. Confirm replication rule exist and works well.
|
||||
7. Confirm project level settings(publicly, content trust, scan) same as before.
|
||||
8. Confirm system level settings(email token expire scan) same as before.
|
||||
9. Confirm scan result the same as before upgrade.
|
||||
10. Confirm access log the same as before upgrade.
|
||||
11. Confirm repository info the same as before.
|
||||
12. Confirm other image metadata(e.g. author, size) the same as before.
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,48 +1,3 @@
|
||||
### Variables
|
||||
Variable | Description
|
||||
-------------------|-------------
|
||||
BASEIMAGE | Container base image, default: photon
|
||||
DEVFLAG | Build model flag, default: dev
|
||||
COMPILETAG | Compile model flag, default: compile_normal (local golang build)
|
||||
GOBUILDIMAGE | Golang image to compile harbor go source code.
|
||||
NOTARYFLAG | Whether to enable notary in harbor, default:false
|
||||
HTTPPROXY | Clarity proxy to build UI.
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
### Targets
|
||||
Target | Description
|
||||
--------------------|-------------
|
||||
all | prepare env, compile binaries, build images and install images
|
||||
prepare | prepare env
|
||||
compile | compile ui and jobservice code
|
||||
compile_portal | compile portal code
|
||||
compile_core | compile core binary
|
||||
compile_jobservice | compile jobservice binary
|
||||
build | build Harbor docker images (default: using build_photon)
|
||||
build_photon | build Harbor docker images from Photon OS base image
|
||||
install | compile binaries, build images, prepare specific version of compose file and startup Harbor instance
|
||||
start | startup Harbor instance
|
||||
down | shutdown Harbor instance
|
||||
package_online | prepare online install package
|
||||
package_offline | prepare offline install package
|
||||
pushimage | push Harbor images to specific registry server
|
||||
clean all | remove binary, Harbor images, specific version docker-compose file, specific version tag and online/offline install package
|
||||
cleanbinary | remove ui and jobservice binary
|
||||
cleanimage | remove Harbor images
|
||||
cleandockercomposefile | remove specific version docker-compose
|
||||
cleanversiontag | remove specific version tag
|
||||
cleanpackage | remove online/offline install package
|
||||
version | set harbor version
|
||||
|
||||
#### EXAMPLE:
|
||||
|
||||
#### Build and run harbor from source code.
|
||||
make install GOBUILDIMAGE=golang:1.13.4 COMPILETAG=compile_golangimage NOTARYFLAG=true
|
||||
|
||||
### Package offline installer
|
||||
make package_offline GOBUILDIMAGE=golang:1.13.4 COMPILETAG=compile_golangimage NOTARYFLAG=true
|
||||
|
||||
### Start harbor with notary
|
||||
make -e NOTARYFLAG=true start
|
||||
|
||||
### Stop harbor with notary
|
||||
make -e NOTARYFLAG=true down
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
@ -1,26 +1,3 @@
|
||||
### Setup
|
||||
This content has moved. For the Harbor 1.10 docs, please go to https://github.com/goharbor/harbor/blob/master/docs/1.10/index.md.
|
||||
|
||||
In harbor.yml, make sure https is enabled, and the attributes `ssl_cert` and `ssl_cert_key` are pointed to valid certificates. For more information about generating https certificate please refer to: [Configuring HTTPS for Harbor](configure_https.md)
|
||||
|
||||
### Copy Root Certificate
|
||||
|
||||
Suppose the Harbor instance is hosted on a machine `192.168.0.5`
|
||||
If you are using a self-signed certificate, make sure to copy the CA root cert to `/etc/docker/certs.d/192.168.0.5/` and `~/.docker/tls/192.168.0.5:4443/`
|
||||
|
||||
### Enable Docker Content Trust
|
||||
|
||||
It can be done via setting environment variables:
|
||||
|
||||
```
|
||||
export DOCKER_CONTENT_TRUST=1
|
||||
export DOCKER_CONTENT_TRUST_SERVER=https://192.168.0.5:4443
|
||||
```
|
||||
|
||||
### Set alias for notary (optional)
|
||||
|
||||
Because by default the local directory for storing meta files for notary client is different from docker client. If you want to use notary client to manipulate the keys/meta files generated by Docker Content Trust, please set the alias to reduce the effort:
|
||||
|
||||
```
|
||||
alias notary="notary -s https://192.168.0.5:4443 -d ~/.docker/trust --tlscacert /etc/docker/certs.d/192.168.0.5/ca.crt"
|
||||
|
||||
```
|
||||
For older versions of the docs, please select the appropriate `release-1.xx.x` branch and go to the `docs` folder.
|
||||
1423
docs/user_guide.md
1423
docs/user_guide.md
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user