diff --git a/content/blog/harbor-1.10-release.md b/content/blog/harbor-1.10-release.md index 0fa0a8096..b4794917a 100644 --- a/content/blog/harbor-1.10-release.md +++ b/content/blog/harbor-1.10-release.md @@ -9,13 +9,13 @@ showPageInfo: true We are excited to announce Harbor 1.10, a release that hardens security and adds security-related features, including a pluggable scanner framework that lets you pair Harbor with popular image scanners, such as Anchore Enterprise and Trivy by Aqua Security. -The Harbor project improved its security posture by identifying and fixing vulnerabilities after undergoing multiple internal and external penetration tests. We now also have a vulnerability [disclosure process](https://github.com/goharbor/harbor/security/policy) that allows the Harbor project to respond to threats in the future. +The Harbor project improved its security posture by identifying and fixing vulnerabilities after undergoing multiple internal and external penetration tests. We now also have a vulnerability [disclosure process](https://github.com/goharbor/harbor/security/policy) that allows the Harbor project to respond to threats in the future. Let’s dive into some of the latest developments. ## Vulnerability Scanning with Pluggable Scanners -Harbor has long been able to scan images in your repositories for security vulnerabilities or exposures by using [Clair](https://github.com/quay/clair). Harbor now extends its scanning capabilities with its out-of-tree [pluggable scanners](https://github.com/goharbor/community/blob/master/proposals/pluggable-image-vulnerability-scanning_proposal.md). +Harbor has long been able to scan images in your repositories for security vulnerabilities or exposures by using [Clair](https://github.com/quay/clair). Harbor now extends its scanning capabilities with its out-of-tree [pluggable scanners](https://github.com/goharbor/community/blob/master/proposals/pluggable-image-vulnerability-scanning_proposal.md). Any cloud native security vendor that has a container image scanner, be it open source or commercial software, can provide an adapter service that implements the [Harbor scanner API](https://editor.swagger.io/?url=https://raw.githubusercontent.com/goharbor/pluggable-scanner-spec/master/api/spec/scanner-adapter-openapi-v1.0.yaml) specification and integrate with Harbor’s scanning workflows. Once the adapter is deployed and mounted at a URL endpoint accessible to Harbor, you can create a corresponding scanner registration under the Interrogation Services settings to activate the underlying scanner. @@ -43,13 +43,13 @@ You can also leverage your existing licenses for commercial scanners, such as An ## Immutable Tags -Harbor system and project administrators can now configure images as immutable, which means another image with matching tags cannot be pushed into the same project in Harbor, thus avoiding accidental overwrites. The Docker distribution does not natively enforce this image tag to image digest mapping, and this behavior can be undesirable for certain release tags that rarely if ever should be tampered with. For example, tags such as ‘rc’, ‘test’, ‘prod’, ‘nightly’ will, over the course of their lifetime, likely migrate across different images as new images are pushed to Harbor while version-specific tags, such as Harbor_v1.6.1, Harbor_v1.7.2, and Harbor_v1.8.3, should be immutable because they are meant to represent a point-in-time snapshot. Once released, a version such as ‘Harbor_v1.8.1’ should never be changed, and any changes should be reflected on the next version, such as ‘Harbor_v1.8.2’. This freezing mechanism provides image traceability and guarantees that an immutable image will always have the same behavior regardless of how subsequent images are pushed, tagged, or retagged. Image immutability can be configured for an entire project, specific repositories, specific tags, or any combination of these. +Harbor system and project administrators can now configure images as immutable, which means another image with matching tags cannot be pushed into the same project in Harbor, thus avoiding accidental overwrites. The Distribution/Distribution does not natively enforce this image tag to image digest mapping, and this behavior can be undesirable for certain release tags that rarely if ever should be tampered with. For example, tags such as ‘rc’, ‘test’, ‘prod’, ‘nightly’ will, over the course of their lifetime, likely migrate across different images as new images are pushed to Harbor while version-specific tags, such as Harbor_v1.6.1, Harbor_v1.7.2, and Harbor_v1.8.3, should be immutable because they are meant to represent a point-in-time snapshot. Once released, a version such as ‘Harbor_v1.8.1’ should never be changed, and any changes should be reflected on the next version, such as ‘Harbor_v1.8.2’. This freezing mechanism provides image traceability and guarantees that an immutable image will always have the same behavior regardless of how subsequent images are pushed, tagged, or retagged. Image immutability can be configured for an entire project, specific repositories, specific tags, or any combination of these. ![Immutability rule](../img/immutability-rule.png) ## OIDC Support Enhancements -In large organizations, identity and permissions are controlled through membership in groups. This is important because permissions can be tied to a group, and different software solutions can leverage the same groups. As an administrator, you only have to add a new employee to the appropriate group to get the correct permissions rather than having to modify multiple software solutions individually. To achieve parity with LDAP and Active Directory group functionality, version 1.10 adds support for OIDC groups. As a project administrator, you can now authorize an OIDC group for a role in Harbor. Members of that group can log in through an OIDC identity provider and inherit the permissions of the groups to which they belong. After an OIDC group is added as a member to a project with a set of permissions associated with a Harbor role, such as that of developers, all users within the OIDC group inherit the same permissions for the project when they log in. Group membership facilitates login workflows for large groups and lets you manage project permissions directly in the registry. +In large organizations, identity and permissions are controlled through membership in groups. This is important because permissions can be tied to a group, and different software solutions can leverage the same groups. As an administrator, you only have to add a new employee to the appropriate group to get the correct permissions rather than having to modify multiple software solutions individually. To achieve parity with LDAP and Active Directory group functionality, version 1.10 adds support for OIDC groups. As a project administrator, you can now authorize an OIDC group for a role in Harbor. Members of that group can log in through an OIDC identity provider and inherit the permissions of the groups to which they belong. After an OIDC group is added as a member to a project with a set of permissions associated with a Harbor role, such as that of developers, all users within the OIDC group inherit the same permissions for the project when they log in. Group membership facilitates login workflows for large groups and lets you manage project permissions directly in the registry. ## Limited Guest @@ -64,11 +64,11 @@ This release saw significant contributions from the community in vulnerability r ## Roadmap for Harbor 2.0 -With [Harbor 2.0](https://github.com/orgs/goharbor/projects/1) aiming to transform itself into a fully OCI-compliant registry, Harbor hopes to be able to host new cloud native artifact types, such as operators, bundles, and RPMs, through supporting a common set of industry-favored APIs called [Open Container Initiative](https://www.opencontainers.org/). This also means that based on an artifact’s type, Harbor would correctly support all corresponding actions of these artifacts, such as when they need to be pushed, scanned, pulled, replicated, and so forth. A direct beneficiary of the proposed refactoring to support OCI would be the ability to delete a single tag off Harbor without deleting all other tags referenced by the same underlying manifest, a major improvement over the Docker distribution. Our plans would also deliver a major enhancement to the current online garbage collection by enabling a non-blocking mechanism that allows you to push images to the registry while garbage collection is taking place, boosting performance and making garbage collection virtually undetectable. +With [Harbor 2.0](https://github.com/orgs/goharbor/projects/1) aiming to transform itself into a fully OCI-compliant registry, Harbor hopes to be able to host new cloud native artifact types, such as operators, bundles, and RPMs, through supporting a common set of industry-favored APIs called [Open Container Initiative](https://www.opencontainers.org/). This also means that based on an artifact’s type, Harbor would correctly support all corresponding actions of these artifacts, such as when they need to be pushed, scanned, pulled, replicated, and so forth. A direct beneficiary of the proposed refactoring to support OCI would be the ability to delete a single tag off Harbor without deleting all other tags referenced by the same underlying manifest, a major improvement over the Distribution/Distribution. Our plans would also deliver a major enhancement to the current online garbage collection by enabling a non-blocking mechanism that allows you to push images to the registry while garbage collection is taking place, boosting performance and making garbage collection virtually undetectable. ## About Harbor -[Harbor](http://goharbor.io) is an open source trusted cloud native registry project that stores, signs, and scans container images and Helm charts. Harbor extends the open source Docker Distribution by adding key enterprise-level features in authentication and access control (LDAP and AD as well as OIDC support for RBAC), two-way replication to and from other third-party registries, advanced online non-blocking garbage collection, and authenticity and provenance capabilities through third-party image scanning and signing solutions. Harbor, which supports Docker Compose and Kubernetes, deploys in under 30 minutes. Harbor can be fully managed through a single web console and comes with a rich set of APIs managed withSwagger. +[Harbor](http://goharbor.io) is an open source trusted cloud native registry project that stores, signs, and scans container images and Helm charts. Harbor extends the open source Distribution/Distribution by adding key enterprise-level features in authentication and access control (LDAP and AD as well as OIDC support for RBAC), two-way replication to and from other third-party registries, advanced online non-blocking garbage collection, and authenticity and provenance capabilities through third-party image scanning and signing solutions. Harbor, which supports Docker Compose and Kubernetes, deploys in under 30 minutes. Harbor can be fully managed through a single web console and comes with a rich set of APIs managed withSwagger. ## Collaborate with the Harbor Community! @@ -80,18 +80,18 @@ Collaborate with us on GitHub: [github.com/goharbor/harbor](https://github.com/g --- -Alex Xu -Harbor Contributor -Product Manager, VMware -github.com/xaleeks +Alex Xu +Harbor Contributor +Product Manager, VMware +github.com/xaleeks -Daniel Pacak -Harbor Maintainer -OSS Engineer, Aqua Security -github.com/danielpacak +Daniel Pacak +Harbor Maintainer +OSS Engineer, Aqua Security +github.com/danielpacak [1]: https://github.com/anchore/harbor-scanner-adapter [2]: https://github.com/aquasecurity/harbor-scanner-aqua [3]: https://github.com/goharbor/harbor-scanner-clair [4]: https://github.com/dosec-cn/harbor-scanner -[5]: https://github.com/aquasecurity/harbor-scanner-trivy \ No newline at end of file +[5]: https://github.com/aquasecurity/harbor-scanner-trivy diff --git a/content/blog/harbor-1.9.md b/content/blog/harbor-1.9.md index 2cf82861b..9040324bd 100644 --- a/content/blog/harbor-1.9.md +++ b/content/blog/harbor-1.9.md @@ -7,11 +7,11 @@ date: 2019-09-18T01:00:00+04:00 showPageInfo: true --- -We are excited to announce the release of Harbor version 1.9, arguably one of our biggest releases packed with several long-awaited features that the open source community has asked for. Thanks to all the members of the community who made contributions to these features, and special thanks in particular to 360 Total Security, Hyland Software, NetEase Cloud, and VMware. With this release, Harbor introduces some key new features: -1. Tag retention and project quotas that strengthen image lifecycle management and security -2. Webhook notifications that enable the integration of Harbor with CI/CD tools -3. Replication targets for the registry services of all the major cloud providers to let you replicate projects based on your business needs -4. CVE exception policies and syslog integration that bring an additional layer of management and security capabilities to Harbor operators +We are excited to announce the release of Harbor version 1.9, arguably one of our biggest releases packed with several long-awaited features that the open source community has asked for. Thanks to all the members of the community who made contributions to these features, and special thanks in particular to 360 Total Security, Hyland Software, NetEase Cloud, and VMware. With this release, Harbor introduces some key new features: +1. Tag retention and project quotas that strengthen image lifecycle management and security +2. Webhook notifications that enable the integration of Harbor with CI/CD tools +3. Replication targets for the registry services of all the major cloud providers to let you replicate projects based on your business needs +4. CVE exception policies and syslog integration that bring an additional layer of management and security capabilities to Harbor operators Let’s deep dive into some of these features. @@ -40,7 +40,7 @@ Harbor currently limits the ability to run certain images that have been scanned ## Replication Improvements -Following the announcement in version 1.8 of cross-registry artifact replication between Harbor and registries such as Docker Hub and Huawei Cloud, version 1.9 expands these capabilities to most major cloud provider registries, such as Amazon Elastic Container Registry, Azure Container Registry, Google Container Registry, and Alibaba Container Registry. Harbor enables seamless two-way replication to third-party registries to meet a multitude of needs and use cases. +Following the announcement in version 1.8 of cross-registry artifact replication between Harbor and registries such as Docker Hub and Huawei Cloud, version 1.9 expands these capabilities to most major cloud provider registries, such as Amazon Elastic Container Registry, Azure Container Registry, Google Container Registry, and Alibaba Container Registry. Harbor enables seamless two-way replication to third-party registries to meet a multitude of needs and use cases. ## Community Call to Action @@ -48,15 +48,15 @@ The 1.9 release saw more input and contributions from the community than ever be ## About Harbor -[Harbor](http://github.com/goharbor/harbor) is an open source trusted cloud native registry project that stores, signs, and scans container images and Helm charts. Harbor extends the open source Docker Distribution by adding key enterprise-level features in authentication and access control (LDAP/AD as well as OIDC support with RBAC), two-way replication to other third-party registries, advanced online garbage collection, and authenticity and provenance capabilities through image scanning and signing. Harbor deploys in under 30 minutes, can be fully managed through a single web console, and comes with a rich set of APIs. +[Harbor](http://github.com/goharbor/harbor) is an open source trusted cloud native registry project that stores, signs, and scans container images and Helm charts. Harbor extends the open source Distribution/Distribution by adding key enterprise-level features in authentication and access control (LDAP/AD as well as OIDC support with RBAC), two-way replication to other third-party registries, advanced online garbage collection, and authenticity and provenance capabilities through image scanning and signing. Harbor deploys in under 30 minutes, can be fully managed through a single web console, and comes with a rich set of APIs. ## Collaborate with the Harbor Community! -Get updates on Twitter ([@project_harbor](https://twitter.com/project_harbor)) -Chat with us on Slack ([#harbor](https://cloud-native.slack.com/messages/harbor) on the [CNCF Slack](https://slack.cncf.io/)) -Collaborate with us on GitHub: [github.com/goharbor/harbor](https://github.com/goharbor/harbor) - -Alex Xu -Harbor Contributor -Product Manager, VMware -[github.com/xaleeks](http://github.com/xaleeks) +Get updates on Twitter ([@project_harbor](https://twitter.com/project_harbor)) +Chat with us on Slack ([#harbor](https://cloud-native.slack.com/messages/harbor) on the [CNCF Slack](https://slack.cncf.io/)) +Collaborate with us on GitHub: [github.com/goharbor/harbor](https://github.com/goharbor/harbor) + +Alex Xu +Harbor Contributor +Product Manager, VMware +[github.com/xaleeks](http://github.com/xaleeks) diff --git a/content/blog/harbor-2.0.md b/content/blog/harbor-2.0.md index 6dc3d5ef6..9e753e4c0 100644 --- a/content/blog/harbor-2.0.md +++ b/content/blog/harbor-2.0.md @@ -166,7 +166,7 @@ Webinar on Harbor v2.0 on May 28, 2020 at 10:00am PDT by registering [Harbor](http://github.com/goharbor/harbor) is an open source, trusted cloud native registry project that stores, signs, and scans container images, Helm charts, and any other OCI-compliant artifacts. Harbor -extends the open-source Docker Distribution by adding key +extends the open-source Distribution/Distribution by adding key enterprise-level features in authentication and access control (LDAP and AD as well as OIDC support for RBAC), two-way replication to and from other third-party registries, advanced garbage collection, and @@ -192,7 +192,7 @@ github.com/goharbor/harbor](https://github.com/goharbor/harbor) Attend the community meetings: [https://github.com/goharbor/community/wiki/Harbor-Community-Meetings](https://github.com/goharbor/community/wiki/Harbor-Community-Meetings) -Alex Xu -Harbor Contributor -Senior Product Manager, VMware +Alex Xu +Harbor Contributor +Senior Product Manager, VMware [@xaleeks](https://github.com/xaleeks) diff --git a/content/blog/harbor-2.2.md b/content/blog/harbor-2.2.md index 40abf6e64..55a09b8ed 100644 --- a/content/blog/harbor-2.2.md +++ b/content/blog/harbor-2.2.md @@ -87,7 +87,7 @@ In 2021, the team will focus on edge nodes - Increasing our involvement in Notary v2 upstream for better image provenance capabilities -- Increasing our involvement in Docker Distribution upstream +- Increasing our involvement in Distribution/Distribution upstream - Strengthening ecosystem partnerships - Integrations with image scanner vendors like Twistlock and Qualys - Improving performance and scalability @@ -127,14 +127,14 @@ contributions to the project! ## Collaborate with the Harbor Community -Get updates on Twitter: [@project\_harbor](https://twitter.com/project_harbor) +Get updates on Twitter: [@project\_harbor](https://twitter.com/project_harbor) Chat with us on Slack: [#harbor](https://cloud-native.slack.com/messages/harbor) and [#harbor-dev](https://cloud-native.slack.com/messages/harbor-dev) -on the[CNCF Slack](https://slack.cncf.io/) -Collaborate with us on [GitHub](https://github.com/goharbor/harbor) +on the[CNCF Slack](https://slack.cncf.io/) +Collaborate with us on [GitHub](https://github.com/goharbor/harbor) Attend the [community meetings](https://github.com/goharbor/community/wiki/Harbor-Community-Meetings) -Alex Xu -Harbor Maintainer -Senior Product Manager, VMware +Alex Xu +Harbor Maintainer +Senior Product Manager, VMware [@xaleeks](https://github.com/xaleeks) diff --git a/content/blog/harbor-2.6.md b/content/blog/harbor-2.6.md index 924ae0683..6241a3844 100644 --- a/content/blog/harbor-2.6.md +++ b/content/blog/harbor-2.6.md @@ -28,9 +28,9 @@ Full article can be found [here](https://github.com/goharbor/perf/wiki/Cache-lay ### CVE export: #### Motivation -Kubernetes and container adoption is witnessing widespread adoption as detailed within the [CNCF survey](https://www.cncf.io/announcements/2022/02/10/cncf-sees-record-kubernetes-and-container-adoption-in-2021-cloud-native-survey/) conducted in February 2022. This trend ultimately bolsters the most fundamental fact - container registries can no longer act as image stores. Instead container registries are now fundamental building blocks for the software supply chain within the cloud-native software realm and hence must expose features that allow the users to assess the software compliance of the images which are stored in the registry. One of the critical parameters for ensuring software compliance is assessing software vulnerabilities present within container images +Kubernetes and container adoption is witnessing widespread adoption as detailed within the [CNCF survey](https://www.cncf.io/announcements/2022/02/10/cncf-sees-record-kubernetes-and-container-adoption-in-2021-cloud-native-survey/) conducted in February 2022. This trend ultimately bolsters the most fundamental fact - container registries can no longer act as image stores. Instead container registries are now fundamental building blocks for the software supply chain within the cloud-native software realm and hence must expose features that allow the users to assess the software compliance of the images which are stored in the registry. One of the critical parameters for ensuring software compliance is assessing software vulnerabilities present within container images -Harbor is an open-source enterprise-grade registry that extends the Docker distribution to provide features such as image vulnerability scanning, replication and activity auditing. +Harbor is an open-source enterprise-grade registry that extends the Distribution/Distribution to provide features such as image vulnerability scanning, replication and activity auditing. With the upcoming 2.6.0 release, Harbor now exposes a mechanism to export CVE vulnerabilities for images to the automation friendly CSV format. The functionality hence unlocks further visibility and control over the security posture of images and their distribution. #### Feature overview @@ -93,7 +93,7 @@ For full information please check the [Harbor v2.6.0 official documentation](htt ### Purge and Forward Audit Log -The audit_log is used to record the image pull/push/delete operations so that administrators could retrieve the history of the operation log. In a typical large Harbor server, there might be a large amount pull request and small amount of push request, delete request. Because the audit log is stored in database table, it cost of amount DB IO time and disk space to write the audit_log, it is better to provide a configurable way to log these information in either the file system or database. The audit_log table because of it is large size, it requires the DBA to create a job to clean up it periodically and it also cause the historical data cannot be retrieved. the purge and forward audit log feature provide a way to forward the audit log to external endpoint and purge the audit log table periodically. +The audit_log is used to record the image pull/push/delete operations so that administrators could retrieve the history of the operation log. In a typical large Harbor server, there might be a large amount pull request and small amount of push request, delete request. Because the audit log is stored in database table, it cost of amount DB IO time and disk space to write the audit_log, it is better to provide a configurable way to log these information in either the file system or database. The audit_log table because of it is large size, it requires the DBA to create a job to clean up it periodically and it also cause the historical data cannot be retrieved. the purge and forward audit log feature provide a way to forward the audit log to external endpoint and purge the audit log table periodically. #### Feature overview @@ -159,17 +159,17 @@ Special thank you to all new contributors: ## Collaborate with the Harbor Community -Get updates on Twitter: [@project\_harbor](https://twitter.com/project_harbor) +Get updates on Twitter: [@project\_harbor](https://twitter.com/project_harbor) Chat with us on Slack: [#harbor](https://cloud-native.slack.com/messages/harbor) and [#harbor-dev](https://cloud-native.slack.com/messages/harbor-dev) -on the[CNCF Slack](https://slack.cncf.io) -Collaborate with us on [GitHub](https://github.com/goharbor/harbor) -Attend the [community meetings](https://github.com/goharbor/community/wiki/Harbor-Community-Meetings) +on the[CNCF Slack](https://slack.cncf.io) +Collaborate with us on [GitHub](https://github.com/goharbor/harbor) +Attend the [community meetings](https://github.com/goharbor/community/wiki/Harbor-Community-Meetings)     -Orlin Vasilev -Harbor Community Manager -GitHub: [@OrlinVasilev](https://github.com/OrlinVasilev) -Twitter: [@OrlinVasilev](https://twitter.com/OrlinVasilev) \ No newline at end of file +Orlin Vasilev +Harbor Community Manager +GitHub: [@OrlinVasilev](https://github.com/OrlinVasilev) +Twitter: [@OrlinVasilev](https://twitter.com/OrlinVasilev) diff --git a/content/blog/harbor-extending-its-reach.md b/content/blog/harbor-extending-its-reach.md index a81d22d48..73b65f4a9 100644 --- a/content/blog/harbor-extending-its-reach.md +++ b/content/blog/harbor-extending-its-reach.md @@ -59,7 +59,7 @@ Furthermore, leveraging Harbor’s webhooks, a notification can be triggered eac ## About Harbor -[Harbor](https://goharbor.io/) is an open source registry that secures OCI artifacts with policies and role-based access control, ensures images are scanned and free from vulnerabilities, and signs images as trusted. Harbor extends the open-source Docker Distribution, adds two-way replication to third-party registries, and can be fully managed through a web console or a rich set of APIs. Harbor, a CNCF Graduated project, delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud native compute platforms like Kubernetes and Docker +[Harbor](https://goharbor.io/) is an open source registry that secures OCI artifacts with policies and role-based access control, ensures images are scanned and free from vulnerabilities, and signs images as trusted. Harbor extends the open-source Distribution/Distribution, adds two-way replication to third-party registries, and can be fully managed through a web console or a rich set of APIs. Harbor, a CNCF Graduated project, delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud native compute platforms like Kubernetes and Docker ## Collaborate with the Harbor Community! @@ -69,10 +69,10 @@ Collaborate with us on GitHub: [github.com/goharbor/harbor](https://github.com/g Attend the community meetings: https://github.com/goharbor/community/wiki/Harbor-Community-Meetings -Alex Xu -Harbor Maintainer +Alex Xu +Harbor Maintainer [@xaleeks](https://github.com/xaleeks) -Yiyang Huang -Harbor Contributor +Yiyang Huang +Harbor Contributor [@hyy0322](https://github.com/hyy0322) diff --git a/docs/administration/metrics/_index.md b/docs/administration/metrics/_index.md index 4d5d8fee2..85e33e2f1 100644 --- a/docs/administration/metrics/_index.md +++ b/docs/administration/metrics/_index.md @@ -11,7 +11,7 @@ Harbor metrics show data related to * Runtime information from the [GO library](https://github.com/prometheus/client_golang) * Performance metrics about all API requests in core * Number of requests in flight in core -* Metrics provided by the [docker distribution](https://github.com/distribution/distribution/blob/main/notifications/metrics.go) itself +* Metrics provided by the [Distribution/Distribution](https://github.com/distribution/distribution/blob/main/notifications/metrics.go) itself * Some data related to business logic which already exist in the Harbor database Metrics are exposed by several Harbor components: `exporter`, `core`, `jobservice`, and `registry`. In addition to runtime and performance data, these components also expose Harbor specific metrics. The following sections list the available Harbor metrics. @@ -53,7 +53,7 @@ Name | Description | Labels (Values) | Metric type ## Registry Metrics -The following are metrics pulled from the Docker distribution and are available at `:/?comp=registry`. +The following are metrics pulled from the Distribution/Distribution and are available at `:/?comp=registry`. {{< table caption="Metrics exposed by Harbor Core" >}} Name | Description | Labels (Values) |Metric type @@ -86,7 +86,7 @@ Name | Description | Labels (Values) |Metric type To begin accessing your Harbor instance's metrics with Prometheus, 1. Enable exposing metrics in your `harbor.yml` [configuration file](../../install-config/configure-yml-file.md) and set the port and path for metrics to be exposed on. Also see more about [reconfiguring your Harbor instance](../../install-config/reconfigure-manage-lifecycle/). -1. Set up a Prometheus server, see the [Prometheus documentation](https://prometheus.io/docs/prometheus/latest/installation/) for more information on installing. +1. Set up a Prometheus server, see the [Prometheus documentation](https://prometheus.io/docs/prometheus/latest/installation/) for more information on installing. 1. Configure your Prometheus config file to scrape Harbor metrics exposed at your configured port and path. Below is an example scrape config, see the Prometheus documentation for all available [scrape configuration options](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config). ``` @@ -122,7 +122,7 @@ To begin accessing your Harbor instance's metrics with Prometheus, static_configs: - targets: [':'] ``` -1. Once you have configured your Prometheus server to collect your Harbor metrics, you can use [Grafana](https://grafana.com/docs/) to visualize your data. An [example Grafana dashboard](https://github.com/goharbor/harbor/blob/main/contrib/grafana-dashborad/metrics-example.json) is available in the Harbor repo to help you get started visualizing Harbor metrics. +1. Once you have configured your Prometheus server to collect your Harbor metrics, you can use [Grafana](https://grafana.com/docs/) to visualize your data. An [example Grafana dashboard](https://github.com/goharbor/harbor/blob/main/contrib/grafana-dashborad/metrics-example.json) is available in the Harbor repo to help you get started visualizing Harbor metrics. ### From a Kubernetes cluster @@ -147,4 +147,4 @@ You can also use Prometheus to collect metrics from a Harbor instance deployed i 2. Enable Harbor to expose metrics by updating your harbor-helm `values.yaml` file and set `metrics.enabled` to `true`. You can also edit the port and path the metrics are exposed on by updating the available harbor-helm chart [configuration options for metrics](https://github.com/goharbor/harbor-helm#configuration). -Prometheus should now show your Harbor instance's metrics. +Prometheus should now show your Harbor instance's metrics. diff --git a/docs/build-customize-contribute/registry-landscape.md b/docs/build-customize-contribute/registry-landscape.md index fc49933cb..07e2fec48 100644 --- a/docs/build-customize-contribute/registry-landscape.md +++ b/docs/build-customize-contribute/registry-landscape.md @@ -6,7 +6,7 @@ The cloud native ecosystem is moving rapidly—registries and their feature sets This table is maintained by contributions from the Harbor community. If you find something outdated or outright erroneous, please submit a PR and we'll fix it right away. -| Feature | Harbor | Docker Trusted Registry | Quay | Cloud Providers (GCP, AWS, Azure) | Docker Distribution | Artifactory | GitLab | +| Feature | Harbor | Docker Trusted Registry | Quay | Cloud Providers (GCP, AWS, Azure) | Distribution/Distribution | Artifactory | GitLab | | -------------: | :----: | :---------------------: | :-----: | :-------------------------------: | :-----------------: | :---------: | :------: | | Ability to Determine Version of Binaries in Containers | ✓ | ✓ | ✓ | ✗ | ✗ | ? | ? | | Artifact Repository (rpms, git, jar, etc) | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | partial | diff --git a/docs/install-config/_index.md b/docs/install-config/_index.md index 3b3dba5d1..934d59881 100644 --- a/docs/install-config/_index.md +++ b/docs/install-config/_index.md @@ -45,6 +45,6 @@ The table below lists the some of the key components that are deployed when you |Postgresql|14.9| |Redis|7.0.12| |Beego|2.0.6| -|Docker/distribution|2.8.2| +|Distribution/Distribution|2.8.2| |Helm|2.9.1| |Swagger-ui|4.17.1| diff --git a/docs/install-config/customize-token-service.md b/docs/install-config/customize-token-service.md index 15bc0566d..f78501c55 100644 --- a/docs/install-config/customize-token-service.md +++ b/docs/install-config/customize-token-service.md @@ -5,24 +5,24 @@ weight: 60 By default, Harbor uses its own private key and certificate to authenticate with Docker clients. This topic describes how to optionally customize your configuration to use your own key and certificate. -Harbor requires the Docker client to access the Harbor registry with a token. The procedure to generate a token is like [Docker Registry v2 authentication](https://github.com/docker/distribution/blob/master/docs/content/spec/auth/token.md). Firstly, you make a request to the token service for a token. The token is signed by the private key. After that, you make a new request with the token to the Harbor registry, Harbor registry verifies the token with the public key in the root cert bundle. Then Harbor registry authorizes the Docker client to push and pull images. +Harbor requires the Docker client to access the Harbor registry with a token. The procedure to generate a token is like [Distribution Registry v2 authentication](https://github.com/distribution/distribution/blob/main/docs/content/spec/auth/token.md). Firstly, you make a request to the token service for a token. The token is signed by the private key. After that, you make a new request with the token to the Harbor registry, Harbor registry verifies the token with the public key in the root cert bundle. Then Harbor registry authorizes the Docker client to push and pull images. - If you do not already have a certificate, follow the instructions in [Generate a Root Certificate](#gen-cert) to generate a root certificate by using openSSL. - If you already have a certificate, go to [Provide the Certificate to Harbor](#provide-cert). ## Generate a Root Certificate {#gen-cert} - + 1. Generate a private key. ```sh - openssl genrsa -out private_key.pem 4096 + openssl genrsa -out private_key.pem 4096 ``` - -1. Generate a certificate. + +1. Generate a certificate. ```sh openssl req -new -x509 -key private_key.pem -out root.crt -days 3650 - ``` + ``` 1. Enter information to include in your certificate request. @@ -42,7 +42,7 @@ Harbor requires the Docker client to access the Harbor registry with a token. Th See [Run the Installer Script](run-installer-script.md) or [Reconfigure Harbor and Manage the Harbor Lifecycle](reconfigure-manage-lifecycle.md) to install or reconfigure Harbor. After you run `./install` or `./prepare`, Harbor generates several configuration files. You need to replace the original private key and certificate with your own key and certificate. -1. Replace the default key and certificate. +1. Replace the default key and certificate. Assuming that the new key and certificate are in `/root/cert`, and `/srv/harbor/data` was specified as `data_volume` run the following commands: @@ -58,4 +58,4 @@ See [Run the Installer Script](run-installer-script.md) or [Reconfigure Harbor a docker-compose up -d ``` -1. Push and pull images to and from Harbor to check that your own certificate works. +1. Push and pull images to and from Harbor to check that your own certificate works. diff --git a/docs/install-config/harbor-compatibility-list.md b/docs/install-config/harbor-compatibility-list.md index 441078563..5d8005f57 100644 --- a/docs/install-config/harbor-compatibility-list.md +++ b/docs/install-config/harbor-compatibility-list.md @@ -10,7 +10,7 @@ This document provides compatibility information for all Harbor components. | | Registries | Pull Mode | Push Mode | Proxy Cache | Introduced in Release | Automated Pipeline Covered | |-----|------------------|-----------|-----------|-----------------------|-----------------------|---------------------------| | [Harbor](https://goharbor.io/)| ![Harbor](../../img/replication-adapters/harbor-logo.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)| V1.8 | ![Y](../../img/replication-adapters/right.png) | -| [distribution](https://github.com/docker/distribution) | ![distribution](../../img/replication-adapters/distribution.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)| V1.8 | ![Y](../../img/replication-adapters/right.png) | +| [distribution](https://github.com/distribution/distribution) | ![distribution](../../img/replication-adapters/distribution.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)| V1.8 | ![Y](../../img/replication-adapters/right.png) | | [docker hub](https://hub.docker.com/) | ![docker hub](../../img/replication-adapters/docker-hub.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)| V1.8 | ![Y](../../img/replication-adapters/right.png) | | [Huawei SWR](https://www.huaweicloud.com/en-us/product/swr.html) | ![Huawei SWR](../../img/replication-adapters/hw.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)| ![N](../../img/replication-adapters/no.png) |V1.8 | ![N](../../img/replication-adapters/no.png) | | [GCR](https://cloud.google.com/container-registry/) | ![GCR](../../img/replication-adapters/gcr.png)|![Y](../../img/replication-adapters/right.png)|![Y](../../img/replication-adapters/right.png)| ![Y](../../img/replication-adapters/right.png)|V1.9 | ![Y](../../img/replication-adapters/right.png) | diff --git a/docs/working-with-projects/working-with-images/create-tag-immutability-rules.md b/docs/working-with-projects/working-with-images/create-tag-immutability-rules.md index dfb213e4c..d6951c9be 100644 --- a/docs/working-with-projects/working-with-images/create-tag-immutability-rules.md +++ b/docs/working-with-projects/working-with-images/create-tag-immutability-rules.md @@ -3,11 +3,11 @@ title: Tag Immutability Rules weight: 85 --- -By default, users can repeatedly push an artifact with the same tag to a repository in Harbor. This causes the tag to migrate across the artifacts and every artifact that has its tag taken away becomes tagless. This is due to Docker distribution upstream which does not enforce the mapping between an image tag and the image digest. This can be undesirable in certain cases, because the tag can no longer be trusted to identify the image version. The sha256 digest remains reliable and always points to the same build, but it is not rendered in a human-readable format. +By default, users can repeatedly push an artifact with the same tag to a repository in Harbor. This causes the tag to migrate across the artifacts and every artifact that has its tag taken away becomes tagless. This is due to Distribution/Distribution upstream which does not enforce the mapping between an image tag and the image digest. This can be undesirable in certain cases, because the tag can no longer be trusted to identify the image version. The sha256 digest remains reliable and always points to the same build, but it is not rendered in a human-readable format. To prevent this, Harbor allows you to configure tag immutability at the project level, so that artifacts with certain tags cannot be pushed into Harbor if their tags match existing tags. This prevents existing artifacts from being overwritten. Tag immutability guarantees that an immutable tagged artifact cannot be deleted, and also cannot be altered in any way such as through re-pushing, re-tagging, or replication from another target registry. -Immutability rules use `OR` logic, so if you set multiple rules and a tag is matched by any of those rules, it is marked as immutable. +Immutability rules use `OR` logic, so if you set multiple rules and a tag is matched by any of those rules, it is marked as immutable. ## How Immutable Tags Prevent Tag Deletion @@ -20,7 +20,7 @@ Since v2.0, you can delete any tag of an artifact without deleting the artifact 1. Push `hello-world:v2` to the project. 1. In the Harbor interface, attempt to delete tag `v1` and `v2` of `hello-world` sequentially. -In this case, you cannot delete tag `v1` as it's an immutable tag and you cannot delete the artifact `hello-world` holding this tag. But you can delete tag `v2` even it shares the sha256 digest with `v1`. +In this case, you cannot delete tag `v1` as it's an immutable tag and you cannot delete the artifact `hello-world` holding this tag. But you can delete tag `v2` even it shares the sha256 digest with `v1`. ## Create a Tag Immutability Rule @@ -33,14 +33,14 @@ In this case, you cannot delete tag `v1` as it's an immutable tag and you cannot - In the **Respositories** row, enter a comma-separated list of repositories to which to either apply or exclude from the rule by selecting either **matching** or **excluding** from the drop-down menu. - In the **Tags** row, enter a comma-separated list of tags to which to either apply or exclude from the rule by selecting either **matching** or **excluding** from the drop-down menu. - + ![Add an immutability rule](../../../img/add-immutability-rule.png) 1. Click **Add** to save the rule. - You can add a maximum of 15 immutability rules per project. + You can add a maximum of 15 immutability rules per project. After you add a rule, any tags that are identified by the rule are marked **Immutable** in the Repositories tab. -1. To modify an existing rule, use the **Action** drop-down menu next to a rule to deactivate, edit, or delete that rule. +1. To modify an existing rule, use the **Action** drop-down menu next to a rule to deactivate, edit, or delete that rule. ![Immutability rules](../../../img/edit-tag-immutability.png) diff --git a/harbor b/harbor index 39ca918ff..04a140332 160000 --- a/harbor +++ b/harbor @@ -1 +1 @@ -Subproject commit 39ca918ffea882ed17a71ac94e0f956688e2c6e5 +Subproject commit 04a140332ef92e12531fc0b5b839d3222036b8b0