 let's get started. Hey everyone, thanks for tuning in. I'm very happy to be here to talk to you guys about Project Harbor. I'm Daniel. I'm a software engineer from VMware. I'm also a maintainer of Harbor. Today with me is my co-presenter Wang Yan. Yan, you want to say hi to the audience? Hi, I'm Yan. I'm also a Harbor maintainer and I work with my partner in Harbor team. Okay, thanks Yan. Now first, because we only have one maintainer session in this coupon, I'll start by giving an introduction to this project for those who are new. Harbor is an on-prem cloud native registry. We started the project by adding features around the Docker distribution to provide a better experience for managing Docker images. Later, with the growth of the user base, more management features were added. Then in a major upgrade, we expand the scope of Harbor for managing only container images to all the OCI cloud native artifacts. With great support from the community, Harbor has officially become a graduated project in CNCF since last year, which is really exciting. Let's take a look at the key features. Harbor provides the access control for the artifacts. The artifacts are isolated within projects. A user is granted the permission to access the artifacts by being added as members to a project. The project is also a unit of management. Admin can assign different policies to products. For example, there's an immutability policy to prevent artifacts from being overridden, and quota policy to limit the storage usage of a product. And the retention policy which can help you remove the spale artifacts so you don't use all the quota too fast. Harbor also provides powerful features to help you distribute the artifacts across different registries in the cloud. You can use the replication to transfer artifacts to or from different registries. And also the proxy cache which helps you configure a project as a cache so the client can get the content from a remote registry synchronously. Security has always been a big concern for enterprise users. To help users to deal with that, Harbor has a flexible scanning framework by implementing the adapters. Scanners can be plugged into Harbor, and admin can trigger the scanner to scan the image or artifact and view the CVEs in the scan report. Harbor also integrates with noddery to support image signing between high security of the workload admin can set the policies in Harbor to prevent image with high CVE scores or invalid signature from being pulled or deployed. Last but not least, with integration with ID managers like LDAP or OIDC providers. And the mechanisms like web hooks, robot accounts, Harbor can work smoothly as an important part in your CICD pipeline. As mentioned before, we have a very healthy community. Throughout the years, more than 200 developers working for more than 50 companies have committed code to the repository. Based on the statistics on our storage service, the installer of Harbor has been downloaded for more than 10,000 times, which is a really big number. We have 12 maintainers coming from five companies and geographically distributed in different countries. I feel extremely happy seeing people with different backgrounds actively making contributions to this product. Once again, I want to say thank you to the community. You guys are really amazing. Having said that, I'm going to pass the mic to Yan to give us a recap about the recent version 2002 release. I'd like to give you a brief introduction about the latest major release of Harbor, that is the 2.2. There are two anchor features in this release, system rubber and the metrics. The system level rubber is targeted to manage multiple projects with one rubber. And the metrics is targeted to expose the system and the runtime information of Harbor instance. And for these two features, I will give a detailed explanation in the next two slides. And besides that, it also introduced the enemy group support in the OIDC Osmo. If the user, if a member of enemy group, the user will have admin advantage in Harbor. And what's more, Harbor 2.2 extends the crosscat list to CR, UCR, Azure, and query support. And one part, the query and the go along version undo some code refactor. So if you'd like to know some details, just refer to the goHarper.io to get the latest documentation. Let's slide, please. And Harbor introduced the first version of the rubber count in 1.8. And since then, we have been getting a lot of feedbacks from the community. Rubber cost enhancement is always concerned and discussed in the community. So after the issue assessment, we decided to introduce the Harbor version 2 in Harbor 2.2. And what we did for the enhancement, I just list them in the table. The first one is the multiple project management. Harbor 2.2 introduces the capability for system admin to create system rubber count. And the system rubber count allows you to use the rubber count to perform maintenance and the repeated tasks across all subsets of projects in your Harbor instance. But for the version 1 of the count, it's just limited into one single project. And the second one is the permissions besides Dover, Elm, and Trout for push. Rubber version 2 has six more permissions like create and delete type, scan image, and so on. System admin can assign any combination of these permissions to a system rubber count to perform your desired task through the OCI client or the Harbor API. Next is the ID. In the Rubber version 1, Harbor issues the GW token as the password of a rubber count and encapsulates all of the information of rubber into that token and does not store any of the information into the database. And because that Harbor has to rely on the GW token to drive to the access scope, announcing of a rubber can be updated. However, in the Rubber version 2, instead of the GW token, Harbor uses the secret as the password, install the access scope permission list, expiration date into the database so that the user can edit them in UI. This is totally not supported in the Rubber version 1. And that is the security management. In the Rubber version 2, you can refresh a Rubber's secrets after it's created, even though you need a new one. This is also a requirement from the community. That user wants Harbor to have a way to refresh the password of a rubber to meet their company's security strategy. That is the token must be rotated periodically. The last one is the prefix definition. This is another hot topic in the community. User wants Harbor to have a way to define the Rubber prefix. Harbor uses this prefix to distinguish a rubber account from a user account. But in Rubber version 1, the prefix is hard coded to rubber dollar and some users can run like it has to escape the dollar factor in their automation script. So in version 2, Harbor opens a prefix configuration. It can be updated to any specific screen without any restrictions. Next slide, please. For the nitrics, it becomes complexity as the number of Harbor components grow. With that also grow the need to monitor its service around the car to maintain the healthy functionality of Harbor. Observability is a key feature for operating a service in production. So in 2.2, Harbor provides a lousy of metrics exposed from users and points. And the observability can give a much more in-depth view of what your Harbor is doing. You can either gain insight into system performance or identify anomalies during one time. So let's start a demo. Okay, let me stop sharing first. Okay, I think you can share a screen. Okay, the first demo is about the rubber account. As you can see, there is a new tag named the rubber accounts. And let me create a system-level rubber first thing. If you want to this rubber to only cover certain projects or be rounded certain permissions, use the project table to select projects and permissions you want to assign to the system rubber account. Here, I just select project one. And after I copy the secret, I will do a docker-locking with the newly created rubber. Up next, I will try to push an image into project one. And then I will try to push an image into project two. You're supposed to get the error message because the rubber had no access. So let's back to Harbor to ground the project two to the rubber panel. Up to save. Have you tried to push the image to project two again? Next is the cover all projects. If you want to use this secret, this system rubber account to cover all projects, use this option. This system rubber account will be able to access all existing and future projects in your Harbor instance. Up to save. Have you created a new project, which name is project three. And then I will try to push an image into project three with the same rubber panel. Yes. The last case is to create a tag. I wish you had a tag with the rubber. We have already pushed a hello word into project one. So now let me use this rubber to add a new tag name demo for the hello word. And let me try to specify the secret at the authentication. And let's back to Harbor to check the late attacks I created by the rubber panel. Next, I will show the secret refresh and the prefix. By default, Harbor will generate a new secret randomly. Or you can choose to enable manually residing the secret. Or entering the new secret here. Adjust the specified Harbor one, two, three, four, five as the new secret of this rubber. And then I will try to update the prefix of the rubber to Harbor at. After that, I will do Docker locking with the updated name and secret. Then let's try to pull an image from Harbor with the updated rubber. One last minor thing is about the legacy rubbers. For the rubbers that created before 2.2, Harbor will add a Lexi label to them. You can still use them as normal, but without any new functionalities. So we can use it to duplicate this Lexi rubbers and use the rubber version one for the stack. Okay, this is the demo for rubber. Let's try to jump to the natural standard. Before demo, I will give you some background about the showcase. I have already set up a monitoring stack for my running Harbor with Prometheus and Grafana. Prometheus acts as a storage backend and Grafana as the interface for analyze on virtualization. Everyone script to simulate the high usage of Harbor users at a particular time. And the script will create 100 projects and do parallel push to the previous projects. And let's see the diagram are being reflected in the Grafana view. Adjust the list of the core and registry metrics here. After the script starts, you will see the project total count change as well as the core and registry deflate request ascent because of the parallel push. This chart can reflect the real-time runtime information of your Harbor users. And this information is important in the context of resource usage, utilization, and cost control. And after the script is done, it will remove all of the projects. So you will see the project total count start to be set. Okay, let's all the demo for 2.0 on the features. I don't know. I'll just stop for a second. Thanks, Yen, for the wonderful demo. Next, I'm going to give you some update about the operator. I recall we gave introduction in the previous KubeCon. We want to provide a relatively simple way for the user to deploy a high available full stack Harbor. By full stack, I mean all the dependent resources like certificates, storage services, database can be deployed with one KubeCon command. For this purpose, we wrap the Minio Redis PD Circle operators. And the resource managed by these operators along with the Harbor CR will be owned by the Harbor cluster CR. So with the help of sermenegrine ingress controller, all the resources can be managed via the Harbor cluster CR. And of course, it has the flexibility to be configured to use existing storage services also. Let me show you the demo. Here, after building the images of operator, I use the customize to generate the YAML. And you saw the operator using KubeCon. You can see all the CRDs and row bindings and deployments for the operators are being created. Let's wait for a few seconds before the operator is ready. If you list the pause, you can see the pause for all the four operators, including Harbor, Minio, Postgres, and Redis. And let's take a look at the manifest YAML file we used to deploy Harbor instance. It contains the definition for the secret, for the admin password, secret for Minio, and certificates. And the certificates for Harbor, which will be managed by the sermenegrine. So you provide DNS name and sermenegrine will generate the cert. And in the spec of Harbor cluster CR, there are attributes for each of the components, including database and internal storage services. You can set the size of PV or the replicas to enable HA. Now, if we feed this YAML file to KubeCon apply, now we created the Harbor cluster CR. And we can monitor the status by checking the CR. If you use the dash or wide, you can check the readiness of the storage services as subcomponents. The reason we can do this is because search information is populated in the status of Harbor cluster CR. And we can see in this namespace, the pods are being created. Minios are ready and Postgres, it needs more time. So I did some editing to keep the video short. The status of Harbor cluster is healthy now and all the pods are running. And we can see there are multiple replicas for the database, Redis and Minio. We did that with only one KubeCon command. And we can use the configure hostname and admin credential to access Harbor and start using it. So at the time the session is recorded, we are still busy ironing out the bugs and bumping up versions. Hopefully, by the time you see this session, there's a release candidate for the Harbor operator. And we are also working with community user to add more custom resources for day two operation, which will be included in the future release of the operator. Just keep an eye on the Harbor operator repo for the latest update. Okay. Now let's go to the version 2.3. Previously, we have been constantly evolving and adding new features to Harbor. But from another perspective, as users have been using Harbor for a relatively long time, and as user data such as artifacts, job records grow, we started to see issues in performance, stability, etc. In version 2.3, we want to refrain from adding too many features, really step back and deal with such growing pains in this release so that we can walk longer. For the performance, we have teamed up with community users to set up a performance working group. We are working together to provide a repeatable way to continuously measure the performance. We are defining the key scenarios, working out scripts to generate data and run automation tests. We are going to find the bottlenecks and iteratively provide fix to improve the performance. You can check the Slack channel we created for this working group and the Go Harbor slash Perth repo, where we will upload the assets such as scripts, test cases, and the reports. Next, as there are more and more community users who are service providers that will provide Harbor as a registry to their customers, we hear requests to build Harbor for environments with different architecture of CPUs. We had some good discussion and decided to provide a scalable approach. We will refine the build process of Harbor to make it more consumable and customizable. There will be different downstream reports created, each of which will focus on a different architecture. They will provide a separate build and verification process to generate the package of Harbor for different environments. Each of them will provide an independent release cycle such that they will not block each other. Currently, there are different groups of community developers working on ARM, on long-sum architectures. Each of them has created the sub-repo, and we have from the multi-ARC working group to cover the work in this area. You can chime in the Slack channel if you are interested. And of course, there are other work items that are planned. We will verify Harbor on the IPv6 environment, provide a declarative way to help admin configure Harbor without having to call the APIs. There has been asked for this for quite a while. I have to say it's not my favorite requirement. And there are quite a few corner cases we need to consider. That's why we keep holding this. But now the proposal has been submitted and you can take a look. As a follow-up for the metric work we did in version 2.2, we will expose more metrics for job service in 2.3. You will be able to monitor the jobs and the number of job queue via promise use. And the maintainers in scanning group are working out a design to extend the schema of scanning reports to show more vulnerabilities. Hopefully in version 2.3 there will be a very concrete design for future implementation. We are also spending substantial effort to finish the API refactor to make sure all the APIs are generated by the new swagger dock and paying off other debts. As for the timeline, 2.3 will be released on June, July timeframe. Stay tuned. Okay, that's all we want to share in this session. If you want to know more, there are different ways to be part of the community. You can communicate via Slack, mail group, or join the bi-weekly community meetings where you see more information and latest status update. You can also participate in the discussion. Okay, I think that's all for this session. Q&A time and stop recording.