Merge pull request #10421 from stuclem/doc-reorg
Doc reorg for Harbor 1.10
@ -0,0 +1,16 @@
|
||||
# Configuring Authentication
|
||||
|
||||
Harbor supports different modes for authenticating users and managing user accounts. You should select an authentication mode as soon as you deploy Harbor.
|
||||
|
||||
**IMPORTANT**: If you create user accounts in the Harbor database, Harbor is locked in database mode. You cannot change to a different authentication mode after you have created local users.
|
||||
|
||||
- [Database Authentication](db_auth.md): You create and manage user accounts directly in Harbor. The user accounts are stored in the Harbor database.
|
||||
- [LDAP/Active Directory Authentication](ldap_auth.md): You connect Harbor to an external LDAP/Active Directory server. The user accounts are created and managed by your LDAP/AD provider.
|
||||
- [OIDC Provider Authentication](oidc_auth.md): You connect Harbor to an external OIDC provider. The user accounts are created and managed by your ODIC provider.
|
||||
|
||||
The Harbor interface offers an option to configure UAA authentication. This authentication mode is not recommended and is not documented in this guide.
|
||||
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
31
docs/1.10/administration/configure_authentication/db_auth.md
Normal file
@ -0,0 +1,31 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Configure Database Authentication
|
||||
|
||||
In database authentication mode, user accounts are stored in the local database. By default, only the Harbor system administrator can create user accounts to add users to Harbor. You can optionally configure Harbor to allow self-registration.
|
||||
|
||||
**IMPORTANT**: If you create users in the database, Harbor is locked in database mode. You cannot change to a different authentication mode after you have created local users.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Under **Administration**, go to **Configuration** and select the **Authentication** tab.
|
||||
1. Leave **Auth Mode** set to the default **Database** option.
|
||||
|
||||
![Database authentication](../../img/db_auth.png)
|
||||
|
||||
1. Optionally select the **Allow Self-Registration** check box.
|
||||
|
||||
![Enable self-registration](../../img/new_self_reg.png)
|
||||
|
||||
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.
|
||||
|
||||
![Enable self-registration](../../img/self-registration-login.png)
|
||||
|
||||
## What to Do Next
|
||||
|
||||
For information about how to create users in database authentication mode, see [Create User Accounts in Database Mode](../managing_users/create_users_db.md).
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
@ -0,0 +1,47 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Configure LDAP/Active Directory Authentication
|
||||
|
||||
If you select LDAP/AD authentication, users whose credentials are stored in an external LDAP or AD server can log in to Harbor directly. In this case, you do not create user accounts in Harbor.
|
||||
|
||||
**IMPORTANT**: You can change the authentication mode from database to LDAP only if no local users have been added to the database. If there is at least one user other than `admin` in the Harbor database, you cannot change the authentication mode.
|
||||
|
||||
Because the users are managed by LDAP or AD, self-registration, creating users, deleting users, changing passwords, and resetting passwords are not supported in LDAP/AD authentication mode.
|
||||
|
||||
If you want to manage user authentication by using LDAP groups, you must enable the `memberof` feature on the LDAP/AD server. With the `memberof` feature, the LDAP/AD user entity's `memberof` attribute is updated when the group entity's `member` attribute is updated, for example by adding or removing an LDAP/AD user from the LDAP/AD group. This feature is enabled by default in Active Directory. For information about how to enable and verify `memberof` overlay in OpenLDAP, see [this technical note]( https://technicalnotes.wordpress.com/2014/04/19/openldap-setup-with-memberof-overlay/).
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Under **Administration**, go to **Configuration** and select the **Authentication** tab.
|
||||
1. Use the **Auth Mode** drop-down menu to select **LDAP**.
|
||||
|
||||
![LDAP authentication](../../img/select_ldap_auth.png)
|
||||
1. Enter the address of your LDAP server, for example `ldaps://10.162.16.194`.
|
||||
1. Enter information about your LDAP server.
|
||||
|
||||
- **LDAP Search DN** and **LDAP Search Password**: When a user logs in to Harbor with their LDAP username and password, Harbor uses these values to bind to the LDAP/AD server. For example, `cn=admin,dc=example.com`.
|
||||
- **LDAP Base DN**: Harbor looks up the user under the LDAP Base DN entry, including the subtree. For example, `dc=example.com`.
|
||||
- **LDAP Filter**: The filter to search for LDAP/AD users. For example, `objectclass=user`.
|
||||
- **LDAP UID**: An attribute, for example `uid`, or `cn`, that is used to match a user with the username. If a match is found, the user's password is verified by a bind request to the LDAP/AD server.
|
||||
- **LDAP Scope**: The scope to search for LDAP/AD users. Select from **Subtree**, **Base**, and **OneLevel**.
|
||||
|
||||
![Basic LDAP configuration](../../img/ldap_auth.png)
|
||||
1. If you want to manage user authentication with LDAP groups, configure the group settings.
|
||||
- **LDAP Group Base DN**: The base DN from which to lookup a group in LDAP/AD. For example, `ou=groups,dc=example,dc=com`.
|
||||
- **LDAP Group Filter**: The filter to search for LDAP/AD groups. For example, `objectclass=groupOfNames`.
|
||||
- **LDAP Group GID**: The attribute used to name an LDAP/AD group. For example, `cn`.
|
||||
- **LDAP Group Admin DN**: All LDAP/AD users in this group DN have Harbor system administrator privileges.
|
||||
- **LDAP Group Membership**: The user attribute usd to identify a user as a member of a group. By default this is `memberof`.
|
||||
- **LDAP Scope**: The scope to search for LDAP/AD groups. Select from **Subtree**, **Base**, and **OneLevel**.
|
||||
|
||||
![LDAP group configuration](../../img/ldap_groups.png)
|
||||
1. Uncheck **LDAP Verify Cert** if the LDAP/AD server uses a self-signed or untrusted certificate.
|
||||
|
||||
![LDAP certificate verification](../../img/ldap_cert_test.png)
|
||||
1. Click **Test LDAP Server** to make sure that your configuration is correct.
|
||||
1. Click **Save** to complete the configuration.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
@ -0,0 +1,98 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Configure OIDC Provider Authentication
|
||||
|
||||
If you select OpenID Connect (OIDC) authentication, users log in to the Harbor interface via an OIDC single sign-on (SSO) provider, such as Okta, KeyCloak, or dex. In this case, you do not create user accounts in Harbor.
|
||||
|
||||
**IMPORTANT**: You can change the authentication mode from database to OIDC only if no local users have been added to the database. If there is at least one user other than `admin` in the Harbor database, you cannot change the authentication mode.
|
||||
|
||||
Because the users are managed by the OIDC provider, self-registration, creating users, deleting users, changing passwords, and resetting passwords are not supported in OIDC authentication mode.
|
||||
|
||||
### Configure Your OIDC Provider
|
||||
|
||||
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).
|
||||
- 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.
|
||||
|
||||
### Configure an OIDC Provider in Harbor
|
||||
|
||||
Before configuring an OIDC provider in Harbor, make sure that your provider is configured correctly according to the preceding section.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Under **Administration**, go to **Configuration** and select the **Authentication** tab.
|
||||
1. Use the **Auth Mode** drop-down menu to select **OIDC**.
|
||||
|
||||
![LDAP authentication](../../img/select_oidc_auth.png)
|
||||
1. Enter information about your OIDC provider.
|
||||
|
||||
- **OIDC Provider Name**: The name of the OIDC provider.
|
||||
- **OIDC Provider Endpoint**: The URL of the endpoint of the OIDC provider.
|
||||
- **OIDC Client ID**: The client ID with which Harbor is registered as client application with the OIDC provider.
|
||||
- **OIDC Client Secret**: The secret for the Harbor client application.
|
||||
- **Group Claim Name**: The name of a custom group claim that you have configured in your OIDC provider, that includes the groups to add to Harbor.
|
||||
- **OIDC Scope**: A comma-separated string listing the scopes to be used during authentication.
|
||||
|
||||
The OIDC scope must contain `openid` and usually also contains `profile` and `email`. To obtain refresh tokens it should also contain `offline_access`. If you are using OIDC groups, a scope must identify the group claim. Check with your OIDC provider administrator for precise details of how to identify the group claim scope, as this differs from vendor to vendor.
|
||||
|
||||
![OIDC settings](../../img/oidc_auth_setting.png)
|
||||
1. Uncheck **Verify Certificate** if the OIDC Provider uses a self-signed or untrusted certificate.
|
||||
1. Verify that the Redirect URI that you configured in your OIDC provider is the same as the one displayed at the bottom of the page.
|
||||
|
||||
![OIDC certificate verification, URI, and test ](../../img/oidc_cert_verification.png)
|
||||
1. Click **Test OIDC Server** to make sure that your configuration is correct.
|
||||
1. Click **Save** to complete the configuration.
|
||||
|
||||
### Log In to Harbor via an OIDC Provider
|
||||
|
||||
When the Harbor system administrator has configured Harbor to authenticate via OIDC a **Login via OIDC Provider** button appears on the Harbor login page.
|
||||
|
||||
![oidc_login](../../img/oidc_login.png)
|
||||
|
||||
**NOTE:** When Harbor is configured authentication via OIDC, the **Username** and **Password** fields are reserved for the local Harbor system administrator to log in.
|
||||
|
||||
1. As a Harbor user, click the **Login via OIDC Provider** button.
|
||||
|
||||
This redirects you to the OIDC Provider for authentication.
|
||||
1. If this is the first time that you are logging in to Harbor with OIDC, specify a user name for Harbor to associate with your OIDC username.
|
||||
|
||||
![Specify Harbor username for OIDC](../../img/oidc_onboard_dlg.png)
|
||||
|
||||
This is the user name by which you are identified in Harbor, which is used when adding you to projects, assigning roles, and so on. If the username is already taken, you are prompted to choose another one.
|
||||
1. After the OIDC provider has authenticated you, you are redirected back to Harbor.
|
||||
|
||||
### Using OIDC from the Docker or Helm CLI
|
||||
|
||||
After you have authenticated via OIDC and logged into the Harbor interface for the first time, you can use the Docker or Helm CLI to access Harbor.
|
||||
|
||||
The Docker and Helm CLIs cannot handle redirection for OIDC, so Harbor provides a CLI secret for use when logging in from Docker or Helm. This is only available when Harbor uses OIDC authentication.
|
||||
|
||||
1. Log in to Harbor with an OIDC user account.
|
||||
1. Click your username at the top of the screen and select **User Profile**.
|
||||
|
||||
![Access user profile](../../img/user_profile.png)
|
||||
1. Click the clipboard icon to copy the CLI secret associated with your account.
|
||||
|
||||
![Copy CLI secret](../../img/profile_dlg.png)
|
||||
1. Optionally click the **...** icon in your user profile to display buttons for automatically generating or manually creating a new CLI secret.
|
||||
|
||||
![Copy CLI secret](../../img/generate_create_new_secret.png)
|
||||
|
||||
A user can only have one CLI secret, so when a new secret is generated or create, the old one becomes invalid.
|
||||
1. If you generated a new CLI secret, click the clipboard icon to copy it.
|
||||
|
||||
You can now use your CLI secret as the password when logging in to Harbor from the Docker or Helm CLI.
|
||||
|
||||
<pre>
|
||||
sh docker login -u testuser -p <i>cli_secret</i> jt-test.local.goharbor.io
|
||||
</pre>
|
||||
|
||||
**NOTE**: The CLI secret is associated with the OIDC ID token. Harbor will try to refresh the token, so the CLI secret will be valid after the ID token expires. However, if the OIDC Provider does not provide a refresh token or the refresh fails, the CLI secret becomes invalid. In this case, log out and log back in to Harbor via your OIDC provider so that Harbor can get a new ID token. The CLI secret will then work again.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
60
docs/1.10/administration/configure_project_settings.md
Normal file
@ -0,0 +1,60 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# 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.
|
||||
![browse project](../../img/new_proj_create.png)
|
||||
|
||||
## Set 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.
|
||||
|
||||
**NOTE**: Default quotas apply to projects that are created after you set or change the default quota. The default quota is not applied to projects that already existed before you set it.
|
||||
|
||||
You can also set quotas on individual projects. If you set a global default quota and you set different quotas on individual projects, the per-project quotas are applied.
|
||||
|
||||
By default, all projects have unlimited quotas for both tags and storage use.
|
||||
|
||||
1. Select the **Project Quotas** view.
|
||||
![Project quotas](../../img/project-quota1.png)
|
||||
1. To set global default quotas on all projects, click **Edit**.
|
||||
|
||||
![Project quotas](../../img/project-quota2.png)
|
||||
1. For **Default artifact count**, enter the maximum number of tags that any project can contain at a given time, or enter `-1` to set the default to unlimited.
|
||||
1. For **Default storage consumption**, enter the maximum quantity of storage that any project can consume, selecting `MB`, `GB`, or `TB` from the drop-down menu, or enter `-1` to set the default to unlimited.
|
||||
![Project quotas](../../img/project-quota3.png)
|
||||
1. Click **OK**.
|
||||
1. To set quotas on an individual project, click the 3 vertical dots next to a project and select **Edit**.
|
||||
![Project quotas](../../img/project-quota4.png)
|
||||
1. For **Default artifact count**, enter the maximum number of tags that this individual project can contain, or enter `-1` to set the default to unlimited.
|
||||
1. For **Default storage consumption**, enter the maximum quantity of storage that this individual project can consume, selecting `MB`, `GB`, or `TB` from the drop-down menu.
|
||||
|
||||
After you set quotas, you can see how much of their quotas each project has consumed.
|
||||
|
||||
![Project quotas](../../img/project-quota5.png)
|
||||
|
||||
### How Harbor Calculates Resource Usage
|
||||
|
||||
When setting project quotas, it is useful to know how Harbor calculates tag numbers and storage use, especially in relation to image pushing, retagging, and garbage collection.
|
||||
|
||||
- Harbor computes image size when blobs and manifests are pushed from the Docker client.
|
||||
- Harbor computes tag counts when manifests are pushed from the Docker client.
|
||||
|
||||
**NOTE**: When users push an image, the manifest is pushed last, after all of the associated blobs have been pushed successfully to the registry. If several images are pushed concurrently and if there is an insufficient number of tags left in the quota for all of them, images are accepted in the order that their manifests arrive. Consequently, an attempt to push an image might not be immediately rejected for exceeding the quota. This is because there was availability in the tag quota when the push was initiated, but by the time the manifest arrived the quota had been exhausted.
|
||||
- Shared blobs are only computed once per project. In Docker, blob sharing is defined globally. In Harbor, blob sharing is defined at the project level. As a consequence, overall storage usage can be greater than the actual disk capacity.
|
||||
- Retagging images reserves and releases resources:
|
||||
- If you retag an image within a project, the tag count increases by one, but storage usage does not change because there are no new blobs or manifests.
|
||||
- If you retag an image from one project to another, the tag count and storage usage both increase.
|
||||
- During garbage collection, Harbor frees the storage used by untagged blobs in the project.
|
||||
- If the tag count reaches the limit, image blobs can be pushed into a project and storage usage is updated accordingly. You can consider these blobs to be untagged blobs. They can be removed by garbage collection, and the storage that they consume is returned after garbage colletion.
|
||||
- Helm chart size is not calculated. Only tag counts are calculated.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
@ -0,0 +1,13 @@
|
||||
# Configuring Replication
|
||||
|
||||
Replication allows users to replicate resources, namely images and charts, between Harbor and non-Harbor registries, in both pull or push mode.
|
||||
|
||||
When the Harbor system administrator has set a replication rule, all resources that match the defined filter patterns are replicated to the destination registry when the triggering condition is met. Each resource that is replicated starts a replication task. If the namespace does not exist in the destination registry, a new namespace is created automatically. If it already exists and the user account that is configured in the replication policy does not have write privileges in it, the process fails. Member information is not replicated.
|
||||
|
||||
There might be some delay during replication based on the condition of the network. If a replication task fails, it is re-scheduled for a few minutes later and retried several times.
|
||||
|
||||
**NOTE:** Due to API changes, replication between different versions of Harbor is not supported.
|
||||
|
||||
- [Create Replication Endpoints](create_replication_endpoints.md)
|
||||
- [Create Replication Rules](create_replication_rules.md)
|
||||
- [Manage Replications](manage_replications.md)
|
@ -0,0 +1,47 @@
|
||||
# Creating Replication Endpoints
|
||||
|
||||
To replicate image repositories from one instance of Harbor to another Harbor or non-Harbor registry, you first create replication endpoints.
|
||||
|
||||
1. Go to **Registries** and click the **+ New Endpoint** button.
|
||||
|
||||
![New replication endpoint](../../img/replication-endpoint1.png)
|
||||
1. For **Provider**, use the drop-down menu to select the type of registry to set up as a replication endpoint.
|
||||
|
||||
The endpoint can be another Harbor instance, or a non-Harbor registry. Currently, the following non-Harbor registries are supported:
|
||||
|
||||
- Docker Hub
|
||||
- Docker registry
|
||||
- AWS Elastic Container Registry
|
||||
- Azure Container Registry
|
||||
- Ali Cloud Container Registry
|
||||
- Google Container Registry
|
||||
- Huawei SWR
|
||||
- Helm Hub
|
||||
- Gitlab
|
||||
- Quay.io
|
||||
- Jfrog Artifactory
|
||||
|
||||
![Replication providers](../../img/replication-endpoint2.png)
|
||||
|
||||
1. Enter a suitable name and description for the new replication endpoint.
|
||||
1. Enter the full URL of the registry to set up as a replication endpoint.
|
||||
|
||||
For example, to replicate to another Harbor instance, enter https://harbor_instance_address:443. The registry must exist and be running before you create the endpoint.
|
||||
1. Enter the Access ID and Access Secret for the endpoint registry instance.
|
||||
|
||||
Use an account that has the appropriate privileges on that registry, or an account that has write permission on the corresponding project in a Harbor registry.
|
||||
|
||||
**NOTES**:
|
||||
- AWS ECR adapters should use access keys, not a username and password. The access key should have sufficient permissions, such as storage permission.
|
||||
- Google GCR adapters should use the entire JSON key generated in the service account. The namespace should start with the project ID.
|
||||
1. Optionally, select the **Verify Remote Cert** check box.
|
||||
|
||||
Deselect the check box if the remote registry uses a self-signed or untrusted certificate.
|
||||
1. Click **Test Connection**.
|
||||
1. When you have successfully tested the connection, click **OK**.
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
![browse project](../../img/manage_registry.png)
|
@ -0,0 +1,58 @@
|
||||
# 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).
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Replications**.
|
||||
|
||||
![Add a replication rule](../../img/replication-rule1.png)
|
||||
1. Click **New Replication Rule**.
|
||||
1. Provide a name and description for the replication rule.
|
||||
1. Select **Push-based** or **Pull-based** replication, depending on whether you want to replicate images to or from the remote registry.
|
||||
|
||||
![Replication mode](../../img/replication-rule2.png)
|
||||
1. For **Source resource filter**, identify the images to replicate.
|
||||
|
||||
![Replication filters](../../img/replication-rule3.png)
|
||||
|
||||
* **Name**: Replicate resources with a given name by entering an image name or fragment.
|
||||
* **Tag**: Replicate resources with a given tag by entering a tag name or fragment.
|
||||
* **Label**: Replicate resources with a given label by using the drop-down menu to select from the available labels.
|
||||
* **Resource**: Replicate images, charts, or both.
|
||||
|
||||
The name filter and tag filters support the following patterns:
|
||||
|
||||
* **\***: Matches any sequence of non-separator characters `/`.
|
||||
* **\*\***: Matches any sequence of characters, including path separators `/`.
|
||||
* **?**: Matches any single non-separator character `/`.
|
||||
* **{alt1,...}**: Matches a sequence of characters if one of the comma-separated alternatives matches. are as follows:
|
||||
* **\***: Matches any sequence of non-separator characters `/`.
|
||||
* **\*\***: Matches any sequence of characters, including path separators `/`.
|
||||
* **?**: Matches any single non-separator character `/`.
|
||||
* **{alt1,...}**: Matches a sequence of characters if one of the comma-separated alternatives matches.
|
||||
|
||||
**NOTE:** You must add `library` if you want to replicate the official images of Docker Hub. For example, `library/hello-world` matches the official hello-world images.
|
||||
|
||||
Pattern | String(Match or not)
|
||||
---------- | -------
|
||||
`library/*` | `library/hello-world`(Y)<br> `library/my/hello-world`(N)
|
||||
`library/**` | `library/hello-world`(Y)<br> `library/my/hello-world`(Y)
|
||||
`{library,goharbor}/**` | `library/hello-world`(Y)<br> `goharbor/harbor-core`(Y)<br> `google/hello-world`(N)
|
||||
`1.?` | `1.0`(Y)<br> `1.01`(N)
|
||||
1. Use the **Destination Registry** drop-down menu to select from the configured replication endpoints.
|
||||
1. Enter the name of the namespace in which to replicate resources in the **Destination namespace** text box.
|
||||
|
||||
If you do not enter a namespace, resources are placed in the same namespace as in the source registry.
|
||||
|
||||
![Destination and namespaces](../../img/replication-rule4.png)
|
||||
1. Use the Trigger Mode drop-down menu to select how and when to run the rule.
|
||||
* **Manual**: Replicate the resources manually when needed. **Note**: Deletion operations are not replicated.
|
||||
* **Scheduled**: Replicate the resources periodically by defining a cron job. **Note**: Deletion operations are not replicated.
|
||||
* **Event Based**: When a new resource is pushed to the project, or an image is retagged, it is replicated to the remote registry immediately. If you select the `Delete remote resources when locally deleted`, if you delete an image, it is automatically deleted from the replication target.
|
||||
|
||||
**NOTE**: You can filter images for replication based on the labels that are applied to the images. However, changing a label on an image does not trigger replication. Event-based replication is limited to pushing, retagging, and deleting images.
|
||||
|
||||
![Trigger mode](../../img/replication-rule5.png)
|
||||
|
||||
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.
|
@ -0,0 +1,19 @@
|
||||
# Running Replication Manually
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Replications**.
|
||||
1. Select a replication rule and click **Replicate**.
|
||||
|
||||
![Add a replication rule](../../img/replication-rule6.png)
|
||||
|
||||
The resources to which the rule is applied start to replicate from the source registry to the destination immediately.
|
||||
1. Click the rule to see its execution status.
|
||||
1. Click the **ID** of the execution to see the details of the replication and the task list. The count of `IN PROGRESS` status in the summary includes both `Pending` and `In Progress` tasks.
|
||||
1. Optionally click **STOP** to stop the replication.
|
||||
1. Click the log icon to see detailed information about the replication task.
|
||||
|
||||
![View replication task](../../img/list_tasks.png)
|
||||
|
||||
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.
|
||||
|
||||
![Delete or edit rule](../../img/replication-rule6.png)
|
39
docs/1.10/administration/garbage_collection.md
Normal file
@ -0,0 +1,39 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Garbage Collection
|
||||
|
||||
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
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Garbage Collection**.
|
||||
1. Select the **'Garbage Collection'** tab.
|
||||
![Garbage collection](../../img/garbage-collection.png)
|
||||
1. To run garbage collection immediately, click **GC Now**.
|
||||
|
||||
When you run garbage collection, Harbor goes into read-only mode. All modifications to the registry are prohibited.
|
||||
|
||||
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
|
||||
|
||||
1. Expand **Administration**, and select **Garbage Collection**.
|
||||
1. Select the **'Garbage Collection'** tab.
|
||||
1. Use the drop down-menu to select how often to run garbage collection.
|
||||
![Schedule garbage collection](../../img/gc_policy.png)
|
||||
* **None**: No garbage collection is scheduled.
|
||||
* **Hourly**: Run garbage collection at the beginning of every hour.
|
||||
* **Daily**: Run garbage collection at midnight every day.
|
||||
* **Weekly**: Run garbage collection at midnight every Saturday.
|
||||
* **Custom**: Run garbage collection according to a `cron` job.
|
||||
1. Click **Save**.
|
||||
1. Select the **History** tab to view records of the 10 most recent garbage collection runs.
|
||||
![Garbage collection history](../../img/gc_history.png)
|
||||
1. Click on the **Logs** link to view the related logs.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
32
docs/1.10/administration/general_settings.md
Normal file
@ -0,0 +1,32 @@
|
||||
[Back to table of contents](../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Configure Global Settings
|
||||
|
||||
You can configure Harbor to connect to an email server, and set the registry in read-only mode.
|
||||
|
||||
## 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.
|
||||
![browse project](../../img//new_config_email.png)
|
||||
|
||||
## 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.
|
||||
![browse project](../../img//read_only.png)
|
||||
|
||||
If it set to true, deleting repository, tag and pushing image will be disabled.
|
||||
![browse project](../../img//read_only_enable.png)
|
||||
|
||||
|
||||
```
|
||||
$ docker push 10.117.169.182/demo/ubuntu:14.04
|
||||
The push refers to a repository [10.117.169.182/demo/ubuntu]
|
||||
0271b8eebde3: Preparing
|
||||
denied: The system is in read only mode. Any modification is prohibited.
|
||||
```
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
18
docs/1.10/administration/index.md
Normal file
@ -0,0 +1,18 @@
|
||||
# Harbor Administration
|
||||
|
||||
This section describes how to configure and maintain Harbor after deployment. These operations are performed by the Harbor system administrator. The Harbor system administrator performs global configuration operations that apply to the whole Harbor instance.
|
||||
|
||||
The operations that are performed by the Harbor system administrator are the following.
|
||||
|
||||
- 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).
|
||||
- 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).
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../index.md)
|
26
docs/1.10/administration/managing_users/create_users_db.md
Normal file
@ -0,0 +1,26 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Create User Accounts in Database Mode
|
||||
|
||||
In database authentication mode, the Harbor system administrator creates user accounts manually.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Under **Administration**, go to **Users**.
|
||||
|
||||
![Create user account](../../img/create_user.png)
|
||||
1. Click **New User**.
|
||||
1. Enter information about the new user.
|
||||
|
||||
![Provide user information](../../img/new_user.png)
|
||||
|
||||
- The username must be unique in the Harbor system
|
||||
- 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.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
38
docs/1.10/administration/managing_users/rbac.md
Normal file
@ -0,0 +1,38 @@
|
||||
[Back to table of contents](../../index.md)
|
||||
|
||||
----------
|
||||
|
||||
# Harbor Role Based Access Control (RBAC)
|
||||
|
||||
Harbor manages images through projects. You provide access to these images to users by including the users in projects and assigning one of the following roles to them.
|
||||
|
||||
![rbac](../../img/rbac.png)
|
||||
|
||||
* **Limited Guest**: A Limited Guest does not have full read privileges for a project. They can pull images but cannot push, and they cannot see logs or the other members of a project. For example, you can create limited guests for users from different organizations who share access to a project.
|
||||
* **Guest**: Guest has read-only privilege for a specified project. They can pull and retag images, but cannot push.
|
||||
* **Developer**: Developer has read and write privileges for a project.
|
||||
* **Master**: Master has elevated permissions beyond those of 'Developer' including the ability to scan images, view replications jobs, and delete images and helm charts.
|
||||
* **ProjectAdmin**: When creating a new project, you will be assigned the "ProjectAdmin" role to the project. Besides read-write privileges, the "ProjectAdmin" also has some management privileges, such as adding and removing members, starting a vulnerability scan.
|
||||
|
||||
Besides the above roles, there are two system-level roles:
|
||||
|
||||
* **Harbor system administrator**: "Harbor system administrator" has the most privileges. In addition to the privileges mentioned above, "Harbor system administrator" can also list all projects, set an ordinary user as administrator, delete users and set vulnerability scan policy for all images. The public project "library" is also owned by the administrator.
|
||||
* **Anonymous**: When a user is not logged in, the user is considered as an "Anonymous" user. An anonymous user has no access to private projects and has read-only access to public projects.
|
||||
|
||||
For full details of the permissions of the different roles, see [User Permissions By Role](user_permissions_by_role.md).
|
||||
|
||||
If you run Harbor in database authentication mode, you create user accounts directly in the Harbor interface. For information about how to create local user accounts, see [Create User Accounts in Database Mode](create_users_db.md).
|
||||
|
||||
If you run Harbor in LDAP/AD or OIDC authentication mode, you create and manage user accounts in your LDAP/AD or OIDC provider. Harbor obtains the users from the LDAP/AD or OIDC server and displays them in the **Users** tab of the Harbor interface.
|
||||
|
||||
## Assigning the Harbor System Administrator Role
|
||||
|
||||
Harbor system administrators can assign the Harbor system administrator role to other users by selecting usernames and clicking **Set as Administrator** in the **Users** tab.
|
||||
|
||||
![browse project](../../img/new_set_admin_remove_user.png)
|
||||
|
||||
To delete users, select a user and click `DELETE`. Deleting user is only supported under database authentication mode.
|
||||
|
||||
----------
|
||||
|
||||
[Back to table of contents](../../index.md)
|
@ -0,0 +1,58 @@
|
||||
# User Permissions By Role
|
||||
|
||||
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.
|
34
docs/1.10/administration/upgrade/roll_back_upgrade.md
Normal file
@ -0,0 +1,34 @@
|
||||
# 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.
|
4
docs/1.10/administration/upgrade/upgrade_harbor.md
Normal file
@ -0,0 +1,4 @@
|
||||
# Upgrading Harbor
|
||||
|
||||
- [Upgrade Harbor and Migrate Data](upgrade_migrate_data.md)
|
||||
- [Roll Back an Upgrade](roll_back_upgrade.md)
|
71
docs/1.10/administration/upgrade/upgrade_migrate_data.md
Normal file
@ -0,0 +1,71 @@
|
||||
# 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.
|
||||
|
||||
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.
|
@ -0,0 +1,23 @@
|
||||
# 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.
|
||||
|
||||
You can set a system-wide CVE whitelist or you can set CVE whitelists on a per-project basis. For information about per-project CVE whitelists, see [Configure a Per-Project CVE Whitelist](../../working_with_projects/configure_project_whitelist.md).
|
||||
|
||||
System-wide CVE whitelists apply to all of the projects in a Harbor instance.
|
||||
|
||||
1. Go to **Configuration** > **System Settings**.
|
||||
1. Under **Deployment security**, click **Add**.
|
||||
![System-wide CVE whitelist](../../img/cve-whitelist1.png)
|
||||
1. Enter the list of CVE IDs to ignore during vulnerability scanning.
|
||||
![Add system CVE whitelist](../../img/cve-whitelist2.png)
|
||||
|
||||
Either use a comma-separated list or newlines to add multiple CVE IDs to the list.
|
||||
1. Click **Add** at the bottom of the window to add the list.
|
||||
1. Optionally uncheck the **Never expires** checkbox and use the calendar selector to set an expiry date for the whitelist.
|
||||
![Add system CVEs](../../img/cve-whitelist3.png)
|
||||
1. Click **Save** at the bottom of the page to save your settings.
|
||||
|
||||
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.
|
||||
|
||||
![Add and remove system CVEs](../../img/cve-whitelist4.png)
|
@ -0,0 +1,69 @@
|
||||
# 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.
|
||||
|
||||
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.)
|
||||
|
@ -0,0 +1,39 @@
|
||||
# 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.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Interrogation Services**.
|
||||
![Interrogation Services](../../img/interrogation-services.png)
|
||||
1. Click the **New Scanner** button.
|
||||
1. Enter the information to identify the scanner.
|
||||
- A unique name for this scanner instance, to display in the Harbor interface.
|
||||
- An optional description of this scanner instance.
|
||||
- The address of the API endpoint that the scanner exposes to Harbor.
|
||||
![Add scanner](../../img/add-scanner.png)
|
||||
1. Select how to connect to the scanner from the **Authorization** drop-down menu.
|
||||
![Select scanner authentication method](../../img/scanner-auth.png)
|
||||
- **None**: The scanner allows all connections without any security.
|
||||
- **Basic**: Enter a username and password for an account that can connect to the scanner.
|
||||
- **Bearer**: Paste the contents of a bearer token in the **Token** text box.
|
||||
- **APIKey**: Paste the contents of an API key for the scanner in the **APIKey** text box.
|
||||
1. Optionally select **Skip certificate verification** if the scanner uses a self-signed or untrusted certificate.
|
||||
1. Optionally select **Use internal registry address** if the scanner should connect to Harbor using an internal network address rather than its external URL.
|
||||
|
||||
**NOTE**: To use this option, the scanner must be deployed in a network that allows the scanner to reach Harbor via Harbor's internal network.
|
||||
1. Click **Test Connection** to make sure that Harbor can connect successfully to the scanner.
|
||||
![Test scanner connection](../../img/test-scanner-connection.png)
|
||||
1. Click **Add** to connect Harbor to the scanner.
|
||||
1. Optionally repeat the procedure to add more scanners.
|
||||
1. If you configure multiple scanners, select one and click **Set as Default** to designate it as the default scanner.
|
||||
|
||||
## Vulnerability Metadata
|
||||
|
||||
Vulnerability scanners depend on the vulnerability metadata to complete the analysis process. After the first initial installation, the vulnerability scanner automatically starts to update the metadata database from different vulnerability repositories. The database update might take a while, based on the data size and network connection.
|
||||
|
||||
Depending on the scanner that you use, once the database is ready, the timestamp of the last update is shown in the **Interrogation Services** > **Vulnerability** tab. Currently, only Clair and Anchore provide timestamp information.
|
||||
![browse project](../../img/clair_ready.png)
|
||||
|
||||
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).
|
@ -0,0 +1,11 @@
|
||||
# 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.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Interrogation Services**.
|
||||
1. Select the **Vulnerability** tab and click **Scan Now** to scan all of the images in all projects.
|
||||
|
||||
![Scan all images](../../img/scan_all.png)
|
||||
|
||||
Scanning requires intensive resource consumption. If scanning is in progress, the **Scan Now** button is unavailable.
|
@ -0,0 +1,49 @@
|
||||
# Scan Individual Images
|
||||
|
||||
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 **Scanner** tab.
|
||||
|
||||
The **Scanner** tab shows the details of the scanner that is currently set as the scanner to use for this project.
|
||||
|
||||
![Project scanner tab](../../img/project-scanners.png)
|
||||
1. Click **Edit** to select a different scanner from the list of scanners that are connected to this Harbor instance, and click **OK**.
|
||||
|
||||
![Project scanner tab](../../img/select-scanner.png)
|
||||
|
||||
**NOTE**: If you have selected the **Prevent vulnerable images from running** option in the project **Configuration** tab, the prevention of pulling vulnerable images is determined by the scanner that is set in the project, or by the global default scanner if no scanner is configured specifically for the project. Different scanners might apply different levels of severity to image vulnerabilities.
|
||||
1. Select the **Repositories** tab and select a repository.
|
||||
|
||||
For each tag in the repository, the **Vulnerabilities** column displays the vulnerability scanning status and related information.
|
||||
|
||||
![Tag vulnerability status](../../img/tag-vulnerability-status.png)
|
||||
1. Select a tag, or use the check box at the top to select all tags in the repository, and click the **Scan** button to run the vulnerability scan on this image.
|
||||
|
||||
![Scan an image](../../img/scan_image.png)
|
||||
|
||||
**NOTE**: You can start a scan at any time, unless the status is **Queued** or **Scanning**. If the database has not been fully populated, you should not run a scan. The following statuses are displayed in the **Vulnerabilities** column:
|
||||
|
||||
* **Not Scanned:** The tag has never been scanned.
|
||||
* **Queued:** The scanning task is scheduled but has not run yet.
|
||||
* **Scanning:** The scanning task is in progress and a progress bar is displayed.
|
||||
* **View log:** The scanning task failed to complete. Click **View Log** link to view the related logs.
|
||||
* **Complete:** The scanning task completed successfully.
|
||||
|
||||
If the process completes successfully, the result indicates the overall severity level, with the total number of vulnerabilities found for each severity level, and the number of fixable vulnerabilities.
|
||||
|
||||
![Scan result](../../img/scan-result.png)
|
||||
|
||||
* **Red:** At least one critical vulnerability found
|
||||
* **Orange:** At least one high level vulnerability found
|
||||
* **Yellow:** At least one medium level vulnerability found
|
||||
* **Blue:** At least one low level vulnerability found
|
||||
* **Green:** No vulnerabilities found
|
||||
* **Grey:** Unknown vulnerabilities
|
||||
1. Hover over the number of fixable vulnerabilities to see a summary of the vulnerability report.
|
||||
|
||||
![Vulnerability summary](../../img/vulnerability-summary.png)
|
||||
1. Click on the tag name to see a detailed vulnerability report.
|
||||
|
||||
![Vulnerability report](../../img/tag_detail.png)
|
||||
|
||||
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.
|
@ -0,0 +1,17 @@
|
||||
# Schedule Scans
|
||||
|
||||
You can set policies to control when vulnerability scanning should run.
|
||||
|
||||
1. Log in to the Harbor interface with an account that has Harbor system administrator privileges.
|
||||
1. Expand **Administration**, and select **Interrogation Services**.
|
||||
1. Select the **Vulnerability** tab and click the **Edit** button next to **Schedule to scan all**.
|
||||
1. Use the drop down-menu to select how often to run scans.
|
||||
|
||||
![browse project](../../img/scan_policy.png)
|
||||
|
||||
* **None**: No scans are scheduled.
|
||||
* **Hourly**: Run a scan at the beginning of every hour.
|
||||
* **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**.
|
@ -0,0 +1,20 @@
|
||||
# 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).
|
||||
|
||||
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).
|
||||
|
||||
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 All Images](scan_all_images.md)
|
||||
- [Schedule Scans](schedule_scans.md)
|
||||
- [Configure System-Wide CVE Whitelists](configure_system_whitelist.md)
|
||||
|
178
docs/1.10/build_customize_contribute/compile_guide.md
Normal file
@ -0,0 +1,178 @@
|
||||
# Build Harbor from Source Code
|
||||
|
||||
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.12.5
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor without Notary:
|
||||
|
||||
```sh
|
||||
$ make install GOBUILDIMAGE=golang:1.12.5 COMPILETAG=compile_golangimage
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor with Notary:
|
||||
|
||||
```sh
|
||||
$ make install GOBUILDIMAGE=golang:1.12.5 COMPILETAG=compile_golangimage NOTARYFLAG=true
|
||||
```
|
||||
|
||||
- Build, install and bring up Harbor with Clair:
|
||||
|
||||
```sh
|
||||
$ make install GOBUILDIMAGE=golang:1.12.5 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
|
||||
|
||||
```
|
71
docs/1.10/build_customize_contribute/configure_swagger.md
Normal file
@ -0,0 +1,71 @@
|
||||
# View and test Harbor REST API via Swagger
|
||||
A Swagger file is provided for viewing and testing 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.
|
||||
|
||||
![Swagger Editor](img/swaggerEditor.png)
|
||||
|
||||
### 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/docs/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**.
|
||||
|
||||
![Harbor API](img/renderedSwagger.png)
|
38
docs/1.10/build_customize_contribute/customize_look_feel.md
Normal file
@ -0,0 +1,38 @@
|
||||
# Customize the look & feel of Harbor
|
||||
|
||||
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.
|
58
docs/1.10/build_customize_contribute/developer_guide_i18n.md
Normal file
@ -0,0 +1,58 @@
|
||||
## Developing for Internationalization
|
||||
|
||||
*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.
|
11
docs/1.10/build_customize_contribute/index.md
Normal file
@ -0,0 +1,11 @@
|
||||
# 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)
|
20
docs/1.10/build_customize_contribute/prepare-swagger.sh
Normal file
@ -0,0 +1,20 @@
|
||||
#!/bin/bash
|
||||
SCHEME=http
|
||||
SERVER_IP=reg.mydomain.com
|
||||
set -e
|
||||
echo "Doing some clean up..."
|
||||
rm -f *.tar.gz
|
||||
echo "Downloading Swagger UI release package..."
|
||||
wget https://github.com/swagger-api/swagger-ui/archive/v2.1.4.tar.gz -O swagger.tar.gz
|
||||
echo "Untarring Swagger UI package to the static file path..."
|
||||
mkdir -p ../src/ui/static/vendors
|
||||
tar -C ../src/ui/static/vendors -zxf swagger.tar.gz swagger-ui-2.1.4/dist
|
||||
echo "Executing some processes..."
|
||||
sed -i.bak 's/http:\/\/petstore\.swagger\.io\/v2\/swagger\.json/'$SCHEME':\/\/'$SERVER_IP'\/static\/resources\/yaml\/swagger\.yaml/g' \
|
||||
../src/ui/static/vendors/swagger-ui-2.1.4/dist/index.html
|
||||
sed -i.bak '/jsonEditor: false,/a\ validatorUrl: null,' ../src/ui/static/vendors/swagger-ui-2.1.4/dist/index.html
|
||||
mkdir -p ../src/ui/static/resources/yaml
|
||||
cp swagger.yaml ../src/ui/static/resources/yaml
|
||||
sed -i.bak 's/host: localhost/host: '$SERVER_IP'/g' ../src/ui/static/resources/yaml/swagger.yaml
|
||||
sed -i.bak 's/ \- http$/ \- '$SCHEME'/g' ../src/ui/static/resources/yaml/swagger.yaml
|
||||
echo "Finish preparation for the Swagger UI."
|
32
docs/1.10/build_customize_contribute/registry_landscape.md
Normal file
@ -0,0 +1,32 @@
|
||||
# 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.
|
||||
|
||||
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 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
|
6406
docs/1.10/build_customize_contribute/swagger.yaml
Normal file
@ -0,0 +1,94 @@
|
||||
# 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.
|
||||
|
48
docs/1.10/build_customize_contribute/use_make.md
Normal file
@ -0,0 +1,48 @@
|
||||
### 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.
|
||||
|
||||
### 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
|
BIN
docs/1.10/img/OIDC/auth0.png
Normal file
After Width: | Height: | Size: 3.5 KiB |
BIN
docs/1.10/img/OIDC/dex.png
Normal file
After Width: | Height: | Size: 6.4 KiB |
BIN
docs/1.10/img/OIDC/google_identity.png
Normal file
After Width: | Height: | Size: 3.8 KiB |
BIN
docs/1.10/img/OIDC/keycloak.png
Normal file
After Width: | Height: | Size: 11 KiB |
BIN
docs/1.10/img/OIDC/ping.png
Normal file
After Width: | Height: | Size: 3.5 KiB |
BIN
docs/1.10/img/add-immutability-rule.png
Normal file
After Width: | Height: | Size: 32 KiB |
BIN
docs/1.10/img/add-scanner.png
Normal file
After Width: | Height: | Size: 14 KiB |
BIN
docs/1.10/img/add_group.png
Normal file
After Width: | Height: | Size: 46 KiB |
BIN
docs/1.10/img/add_labels_to_images.png
Normal file
After Width: | Height: | Size: 231 KiB |
BIN
docs/1.10/img/add_labesl_to_chart_versions.png
Normal file
After Width: | Height: | Size: 95 KiB |
BIN
docs/1.10/img/add_oidc_group.png
Normal file
After Width: | Height: | Size: 21 KiB |
BIN
docs/1.10/img/add_robot_account.png
Normal file
After Width: | Height: | Size: 114 KiB |
BIN
docs/1.10/img/add_robot_account_2.png
Normal file
After Width: | Height: | Size: 16 KiB |
BIN
docs/1.10/img/api_explorer_btn.png
Normal file
After Width: | Height: | Size: 34 KiB |
BIN
docs/1.10/img/authorize.png
Normal file
After Width: | Height: | Size: 21 KiB |
BIN
docs/1.10/img/browse_project_repositories.png
Normal file
After Width: | Height: | Size: 208 KiB |
BIN
docs/1.10/img/build_history.png
Normal file
After Width: | Height: | Size: 934 KiB |
BIN
docs/1.10/img/chart_dependencies.png
Normal file
After Width: | Height: | Size: 86 KiB |
BIN
docs/1.10/img/chart_details.png
Normal file
After Width: | Height: | Size: 220 KiB |
BIN
docs/1.10/img/chart_values.png
Normal file
After Width: | Height: | Size: 308 KiB |
BIN
docs/1.10/img/clair_ready.png
Normal file
After Width: | Height: | Size: 41 KiB |
BIN
docs/1.10/img/content_trust.png
Normal file
After Width: | Height: | Size: 198 KiB |
BIN
docs/1.10/img/copy_robot_account_token.png
Normal file
After Width: | Height: | Size: 26 KiB |
BIN
docs/1.10/img/create_user.png
Normal file
After Width: | Height: | Size: 35 KiB |
BIN
docs/1.10/img/cve-whitelist1.png
Normal file
After Width: | Height: | Size: 55 KiB |
BIN
docs/1.10/img/cve-whitelist2.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
docs/1.10/img/cve-whitelist3.png
Normal file
After Width: | Height: | Size: 10 KiB |
BIN
docs/1.10/img/cve-whitelist4.png
Normal file
After Width: | Height: | Size: 4.8 KiB |
BIN
docs/1.10/img/cve-whitelist5.png
Normal file
After Width: | Height: | Size: 82 KiB |
BIN
docs/1.10/img/cve-whitelist6.png
Normal file
After Width: | Height: | Size: 14 KiB |
BIN
docs/1.10/img/db_auth.png
Normal file
After Width: | Height: | Size: 39 KiB |
BIN
docs/1.10/img/disable_delete_robot_account.png
Normal file
After Width: | Height: | Size: 118 KiB |
BIN
docs/1.10/img/download_harbor_certs.png
Normal file
After Width: | Height: | Size: 41 KiB |
BIN
docs/1.10/img/edit-tag-immutability.png
Normal file
After Width: | Height: | Size: 13 KiB |
BIN
docs/1.10/img/edit_description.png
Normal file
After Width: | Height: | Size: 153 KiB |
BIN
docs/1.10/img/filter_chart_versions_by_label.png
Normal file
After Width: | Height: | Size: 212 KiB |
BIN
docs/1.10/img/filter_images_by_label.png
Normal file
After Width: | Height: | Size: 232 KiB |
BIN
docs/1.10/img/garbage-collection.png
Normal file
After Width: | Height: | Size: 36 KiB |
BIN
docs/1.10/img/gc_history.png
Normal file
After Width: | Height: | Size: 28 KiB |
BIN
docs/1.10/img/gc_policy.png
Normal file
After Width: | Height: | Size: 16 KiB |
BIN
docs/1.10/img/generate_create_new_secret.png
Normal file
After Width: | Height: | Size: 23 KiB |
BIN
docs/1.10/img/interrogation-services.png
Normal file
After Width: | Height: | Size: 53 KiB |
BIN
docs/1.10/img/ldap_auth.png
Normal file
After Width: | Height: | Size: 28 KiB |
BIN
docs/1.10/img/ldap_cert_test.png
Normal file
After Width: | Height: | Size: 6.7 KiB |
BIN
docs/1.10/img/ldap_group_addgroup_dialog.png
Normal file
After Width: | Height: | Size: 99 KiB |
BIN
docs/1.10/img/ldap_groups.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
docs/1.10/img/list_chart_versions.png
Normal file
After Width: | Height: | Size: 167 KiB |
BIN
docs/1.10/img/list_charts.png
Normal file
After Width: | Height: | Size: 187 KiB |
BIN
docs/1.10/img/list_tasks.png
Normal file
After Width: | Height: | Size: 250 KiB |
BIN
docs/1.10/img/log_filter.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
docs/1.10/img/log_search_advanced.png
Normal file
After Width: | Height: | Size: 15 KiB |
BIN
docs/1.10/img/log_search_advanced_date.png
Normal file
After Width: | Height: | Size: 31 KiB |
BIN
docs/1.10/img/manage_global_level_labels.png
Normal file
After Width: | Height: | Size: 192 KiB |
BIN
docs/1.10/img/manage_project_level_labels.png
Normal file
After Width: | Height: | Size: 205 KiB |
BIN
docs/1.10/img/manage_registry.png
Normal file
After Width: | Height: | Size: 79 KiB |
BIN
docs/1.10/img/new_add_member.png
Normal file
After Width: | Height: | Size: 19 KiB |
BIN
docs/1.10/img/new_browse_project.png
Normal file
After Width: | Height: | Size: 168 KiB |
BIN
docs/1.10/img/new_config_email.png
Normal file
After Width: | Height: | Size: 220 KiB |
BIN
docs/1.10/img/new_create_project.png
Normal file
After Width: | Height: | Size: 95 KiB |
BIN
docs/1.10/img/new_delete_repo.png
Normal file
After Width: | Height: | Size: 165 KiB |
BIN
docs/1.10/img/new_delete_tag.png
Normal file
After Width: | Height: | Size: 181 KiB |
BIN
docs/1.10/img/new_proj_create.png
Normal file
After Width: | Height: | Size: 180 KiB |
BIN
docs/1.10/img/new_project_log.png
Normal file
After Width: | Height: | Size: 27 KiB |
BIN
docs/1.10/img/new_remove_update_member.png
Normal file
After Width: | Height: | Size: 16 KiB |
BIN
docs/1.10/img/new_robot_account.png
Normal file
After Width: | Height: | Size: 23 KiB |