Merge pull request #11900 from ninjadq/add_doc_for_internal_tls

Add doc for internal tls
This commit is contained in:
Qian Deng 2020-05-13 20:01:36 +08:00 committed by GitHub
commit a12bc4c6cd
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 76 additions and 10 deletions

View File

@ -3,12 +3,12 @@ title: Upgrade Harbor and Migrate Data
weight: 45
---
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.
This guide covers upgrade and migration to version 2.0.0. This guide only covers migration from v1.9.x and later to the current version. If you are upgrading from an earlier version, refer to the migration guide in the `release-1.9.0` branch to upgrade to v1.9.x first, then follow this guide to perform the migration to this version.
If you are upgrading a Harbor instance that you deployed with Helm, see [Upgrading Harbor Deployed with Helm](helm-upgrade.md).
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.
When upgrading an existing Harbor instance to a newer version, you might need to migrate the settings in `harbor.yml`.
Since the migration might alter the database schema and the settings of `harbor.yml`, you should **always** back up your data before any migration.
## Notes
@ -40,16 +40,16 @@ Since the migration might alter the database schema and the settings of `harbor.
```
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.
1. Before upgrading Harbor, perform migration.
The migration tool is in harbor-prepare tools delivered as a docker image. You can pull the image from docker hub. in the following 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]
docker pull goharbor/prepare:[tag]
```
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
@ -58,12 +58,12 @@ Since the migration might alter the database schema and the settings of `harbor.
1. Copy the `harbor.yml.tmp` to `harbor.yml` and upgrade it.
```sh
docker run -it --rm -v ${harbor_yml}:/harbor-migration/harbor-cfg/harbor.yml goharbor/harbor-migrator:[tag] --cfg up
docker run -it --rm -v /:/hostfs goharbor/prepare:[tag] migrate -i ${path to harbor.yml}
```
**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.
1. In the `./harbor` directory, run the `./install.sh` script to install the new Harbor instance.
3. 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.

View File

@ -19,6 +19,7 @@ The standard Harbor installation process involves the following stages:
1. [Download the Harbor Installer](download-installer.md)
1. [Configure HTTPS Access to Harbor](configure-https.md)
1. [Configure the Harbor YML File](configure-yml-file.md)
1. [Configure Enabling Internal TLS](configure-internal-tls.md)
1. [Run the Installer Script](run-installer-script.md)
If installation fails, see [Troubleshooting Harbor Installation](troubleshoot-installation.md).

View File

@ -0,0 +1,48 @@
---
title: Configure Internal TLS communication between Harbor Component
weight: 30
---
By default, The internal communication between Harbor's component (harbor-core,harbor-jobservice,proxy,harbor-portal,registry,registryctl,trivy_adapter,clair_adapter,chartmuseum) use HTTP protocol which might not be secure enough for some production environment. Since Harbor v2.0, TLS can be used for this internal network. In production environments, always use HTTPS is a recommended best practice.
This functionality is introduced via the `internal_tls` in `harbor.yml` file. To enabled internal TLS, set `enabled` to `true` and set the `dir` value to the path of directory that contains the internal cert files.
All certs can be automatically generated by `prepare` tool.
```bash
docker run -v /:/hostfs goharbor/prepare:v2.0 gencert -p /path/to/internal/tls/cert
```
User also can provide their own CA to generate the other certs. Just put certificate and key of the CA on internal tls cert directory and name them as `harbor_internal_ca.key` and `harbor_internal_ca.crt`.
Besides, a user can also provide the certs for all components. However, there are some constraints for the certs:
* First, all certs must be signed by a single unique CA
* Second, the filename of the internal cert and `CN` field on cert file must follow the convention listed below'
|name|usage|CN|
|---|---|---|
|`harbor_internal_ca.key`| ca's key file for internal TLS | N/A |
|`harbor_internal_ca.crt`| ca's certificate file for internal TLS | N/A |
|`core.key`| core's key file | N/A |
|`core.crt`| core's certificate file| `core` |
|`job_service.key`| job_service's key file | N/A |
|`job_service.crt`| job_service's certificate file| `jobservice` |
|`proxy.key`| proxy's key file | N/A |
|`proxy.crt`| proxy's certificate file| `proxy` |
|`portal.key`| portal's key file | N/A |
|`portal.crt`| portal's certificate file| `portal` |
|`registry.key`| registry's key file | N/A |
|`registry.crt`| registry's certificate file| `registry` |
|`registryctl.key`| registryctl's key file | N/A |
|`registryctl.crt`| registryctl's certificate file| `registryctl` |
|`notary_server.key`| notary_server's key file | N/A |
|`notary_server.crt`| notary_server's certificate file| `notary-server` |
|`notary_signer.key`| notary_signer's key file | N/A |
|`notary_signer.crt`| notary_signer's certificate file| `notary-signer` |
|`trivy_adapter.key`| trivy_adapter.'s key file | N/A |
|`trivy_adapter.crt`| trivy_adapter.'s certificate file| `trivy-adapter` |
|`clair.key`| clair's key file | N/A |
|`clair.crt`| clair's certificate file| `clair` |
|`clair_adapter.key`| clair_adapter's key file | N/A |
|`clair_adapter.crt`| clair_adapter's certificate file| `clair-adapter` |
|`chartmuseum.key`| chartmuseum's key file | N/A |
|`chartmuseum.crt`| chartmuseum's certificate file| `chartmuseum` |

View File

@ -60,6 +60,23 @@ You can use certificates that are signed by a trusted third-party CA, or you can
<td valign="top"><code>private_key</code></td>
<td valign="top">The path to the SSL key.</td>
</tr>
<tr>
<td valign="top"><code>internal_tls</code></td>
<td valign="top">&nbsp;</td>
<td valign="top"> Use HTTPS to communicate between harbor components</td>
</tr>
<tr>
<td valign="top">&nbsp;</td>
<td valign="top"><code>enabled</code></td>
<td valign="top">Set this flag to <code>true</code> means internal tls is enabled</td>
</tr>
<tr>
<td valign="top">&nbsp;</td>
<td valign="top"><code>certificate</code></td>
<td valign="top">The path to the directory that contains internal certs and keys</td>
</tr>
<tr>
<td valign="top"><code>harbor_admin_password</code></td>
<td valign="top">None</td>