 All right, everyone. Hello, good afternoon. And welcome to Project Harbor Maintainer Track. I'm here today with Wang Yang and myself, Wadding Bauer. We are two of the maintainers of Project Harbor, and we would like to tell you today what we have planned for our next release and what other things we're currently tinkering with. So let's get started, right? With a quick introduction, what are we currently working on? What is the outlook? And what is going to be part of the next release in a couple of days or weeks? And let's get started. So if you're new to Harbor, Harbor is a CNCF-graduated project that is basically a container registry with a few superpowers. So it's not just about storing new images, but actually going to the next level and managing your images with policies, role-based access control, et cetera, et cetera. So since January, Harbor turned eight, and we are still growing, and I can proudly say that Harbor is one of the most popular container registries out there. If you want to do something more, you can just store images. And this is also some kind of reflected in the stars. Some of the key features of Harbor, you can do access control, you can do artifact distribution, you can do security and compliance, policies and maintainability. This is like all bit of a buzzword here. So I think more interesting is the look from a user perspective. So what do you get as a user or in a different role, right? So the good thing about Harbor is it works for small teams, equally as for large teams. You can really start small with a few people and then you can add role-based access control, your IDP, and you can grow with your organization and in a more mature project, a mature setup over terabytes of size. For CISO, it's quite interesting because you can have a registry where you have all your images in one place. So you can use replication where you can replicate images from different locations, all to the central place. You have vulnerability dashboards, you have vulnerability overview, you have audit trails. So all the things that make CISO happy are included into Harbor. So that's why it makes CISO happy. And my favorite is the Ops people's darling is because we can automate a lot of things. We can implement GitOps workflows. We can use Terraform to manage Harbor or Pulumi and you have quotas so that it doesn't make AWS and Azure happy. You have policies, you have garbage collection and all those things that makes your operation of Harbor quite convenient. And so after a really quick introduction into Harbor, let's take a quick look at Harbor today, what are the things we're currently working on. And there is, before we get started, I would like to mention about our Harbor operator. It was donated to projects some time ago and there have been quite a few users using this project. And it's basically, you know, tool allows you to install and manage Harbor via CRDs. And the situation with the project currently is that it's kind of a bit of outdated. So I think the last stable release was two for something, two for one, I'm not sure. And as you can see, because I'm not sure, it's not really maintained. And this means if you're using this project, I really would highlight or recommend you, you know, join us and start contributing to the project because it's at the stage where we don't have, if you don't have contribution to that, we might archive it. So if you're depending on it and using it and if you want to keep using it, then might be a good chance to contribute to that. One good thing is we're working on a Harbor CLI. There are quite a few CLIs already in the community. There are not always, but few of them are outdated. And we think it makes sense to centralize it and make it a bit officially. So we're working on an official CLI. And I'm very happy to say that the CLI is currently developed by LFX mentorship program mentees. So it started last year and continues this year. So all the development and effort is done by Linux foundation mentorship program. So if you're a student or a young professional and you would like to contribute the next season, this is a perfect opportunity to join here. So we expect it's already public, but you can expect something usable in somewhere in June that you can integrate into your CI CD pipeline and work with that, right? So the goal is to not just use it on a CLI, but also integrate it into the pipelines. Another project that I'm working on or I'm focusing currently is Harbor Satellite. This allows you to bring your registry at the edge so where you can manage thousands of registries all distributed. And this is especially useful for IoT and edge use cases or locations where there is no permanent internet connectivity. And this is something we're currently working on in collaboration with the LFX mentorship program, but also with people from our community. And there is a project, POC should be released also in June somewhere and we expect general availability somewhere in 2024. So there is no clear deadline, but somewhere this year should be something usable and a big thanks to Philip Lane, who is a contributor to Spiegel. If you're using K3S, you probably might have heard about that one. It's a super awesome project and Philip joined Satellite to support us in this effort. So you can expect a bit something in this direction. Right. There is some crazy lab experiment I'm working on and it's about what if we could store other type of artifacts in an OCI registry. In particular, what are the most prominent artifacts out there like MAVEN, NPM. So what if we could store those also in OCI registry? How does it look like? What needs to be done in order to make it happen? Does it make sense? So this is like a crazy lab experiment to see if it's really feasible and the answer is yes, it's feasible. Does it make sense? I don't know, but we can do it. So we can do it as an proxy mode where we can translate the requests into OCI and back or we can do the extension mode where we can extend the CLIs of MAVEN and NPM and support OCI natively and it's a bit of a trade-off. Should we do it? Should we not do it? Does it make sense? Is it a game changer? Is it more the question to your community? Is it a game changer? And if you think it would be a game changer, talk to us and then we can figure it out if it makes sense to continue. Right. And now I would like to hand over to Wang-Yang and he's going to explain what we have up for next release in 2011 and it's going to be about Escom probably, right? So he's... Thank you. Thanks, Wang-Yang. I'm Yang from the Harbor team and currently I'm on the Harbor core maintainer and I'm working with Wang-Yang to maintain the Harbor project and I'm sort of leading this project. Today I will be presenting the latest key features since Harbor 2.10. Yep. This is the first one, the robot full access. We have already done the Harbor robot question UI. So initially this robot concept would mean to have access to nearly all Harbor APIs, but in the earlier versions, only limited access was granted for UI. Let's mean that if you wanted to create a robot with specific permission using API, it could be pretty tricky. But actually we are not familiar with the extensive Harbor API ecosystem which has hundreds of endpoints. To simplify matters, we have supposed up the Harbor UI. We have through in a user interface tutorial that work you through creating a robot step by step. Now all it takes is a single click to specify the permission you need. Easy peasy. So let's try to the first time. I'm trying to create a project liable robot and we break the flow into two steps. In the first step, you are required to input some basic information like name, description, and expiration time. In the second step, you are required to select the permission site like the combination of resource and actions. You can customize any permission site for your robots. You can also select OR or this clock OR. After finish, you can see the created robot in the grid and you can see the selected permission in the proper data. You can also edit the permission as you want. In the next, I will try to create a system liable robot. The similar steps, but with one more step, that is you have to specify the system liable or resource combination. Here I'm trying to specify some basic information for my system liable robot. In the second step, you are asked to select the combination of system resource and actions like replication, image scanning, and so on and so forth. You can also select OR or this clock OR. In this step, you have to ask to select the project coverage for your system liable robot. You can cover OR project or you can customize your project scope. As well as you need to customize the combination of permission for this specific project. After the creation is successfully, you could see the customized scope in the data grid like the project liable robot. What we are doing right now, you may be aware that the OCI community recently dropped its 101 version, making a big milestone because there haven't been any new releases for years. Let me quickly recap the major changes in 101. The first one is the artifact type. With the updated version, you will be able to create any new type of OCI artifact by simplifying this field when building a manifest. Previously, some OCI clients had to resort to using the config media type, while others rely on annotation to work around this limitation. There was no standardized approach. However, with the latest changes, you can easily achieve this through the artifact type. The second one is the subject field. What is the subject field? It is an association from one manifest to another. It might sound a bit abstract, but let me give you some concrete examples to clarify. Imagine that you want to ensure the safety of your artifact. You may want to sign it and use the registry to store the signature. In the version 1.0 of specification, you could only push the signature as a separate OCI artifact. But in version 101, you could now use the subject field to say, hey, this signature belongs to my image. Then this way, the registry will understand the relationship and help you to establish it. The same story for S1, which I'm going to talk about later. The last one is the reference API. It will help the client to understand how many objects belong to one specific artifact and what are they. Let's talk about what we have been up to on HarborSide to support latest specifications. Picture this. You are pushing an image using the Docker client. Then you use Cosign to attach the S1 file to the uploaded image and then use Notation to sign the image. So now on the server side, HarborStuffin will definitely understand what these artifacts are and how they relate to each other. As shown in the chart, we are here to help to build and virtualize these relationships for you. And by the way, in the Harbor dictionary, we are using the word accessory to describe these kind of objects. I mean the signature or S1. So let me demo the 101 support. Firstly, I'm trying to create a demo artifact and then I will try to use the Auras client to upload my demo object. After that, you will see the demo object in the Harbor UI. Let me refresh that. And then I will try to use Notation to sign this demo artifact. And we are using the OCI 101 mode. So you will see there will be a new accessory be attached to the demo we want object and the type is signature.notation. And next, I'm trying to use the cosine to upload an S1 file to point to the demo we want as a substrate manifest. So we are using the 101 mode and pointing to the demo we want. So after that, you will see there are two accessories. The second one is the S1 file. So next, I'm trying to use the Notation to sign this uploaded S1 file. And so after that, you will see there should be three levels for your overall structure. And the last one should be the signature of the S1 file. And then the type is the signature.notation. And last, I will try to use ours to upload an institution file to my demo we want. And the same scenario, we will see there are three accessories attached to this demo we want. Now we are using the 101 mode and pointing to the demo we want. And we are specifying some artifact type. So, yeah, there are three accessories. And the last step is where I'm trying to use Notation to sign the last accessory that I pushed by our last step. So this is the whole structure of your artifact. And then we do have a subject manifest, a signature, an S1, an institution, and the signatures of these two accessories. And then let's try to use the ours discover command to see the structure of your artifacts. The same structure as Harbor shows, right? So here I want to emphasize that both Harbor and the OSI clients, I mean ours, Notation, Cosign, we do not do customer anything for each other. We are simplified coding based on the same specification. I mentioned the distribution spike 101. So let me try to replicate the uploaded demo artifact to another Harbor registry. And here is the demo website. And after the replication is successfully, let's try to check the replicated artifact in the target Harbor. So in the target Harbor, it should keep the same structure as the source. That is, they should have three levels. The first level is the subject and then the last level should be the signatures. Okay. So let's check about the protocol scanner spike. You may already be familiar with how Harbor currently supports 3V as a built-in scanner to sneak off CVE. But did you know that Harbor has the potential to support a whole array of third-party scanners? That's true. All you need to do as a scanner developer is whip up a adapter based on the protocol scanner spike. This spike essentially lists down the rules for how a scanner should interact with Harbor to carry out the artifact scanning. In our latest release 102, we are all about enhancing this spike. We want to make it even more adaptable or flexible so that it can unlock more of scanner's capabilities. Right now, we are focusing on the CVE scanning, but we are adding a spawn for the NASA moon. Beyond that, we are thinking about tackling CIS and misconfiguration. So, my data, which is basically the description of a scanner, including what it can do. But in the previous version, the description was pretty basic. Now in the 102, we have stabbed it up a notch. We have enhanced the response to provide more detailed information. When a scanner communicates, it can now specify its exact capabilities. For instance, it can tell Harbor that it can support spawn generation, secret scanning, CVE scanning, and other similar functions. So with the upgraded response, when Harbor sends out a scanning request, it can now specify the process capabilities needed for a scanner to get a drop-down. For instance, Harbor might send out a scanning request that requires both a CVE spawn scanning capabilities. And by the way, we are collaborating with the travel team to make this happen. Let's delve into the spawn support. Ensuring the safety of your artifacts is our utmost priority. And the spawn support is a crucial area. So we are aiming to utilize the changes in the distribution spike, proper scanner spike, to bring spawn support to Harbor. For example, with the updates in the proper scanner spike, Harbor could prompt Trivi to create an spawn for any necessary artifacts. Additionally, leveraging the adjustments in the distribution spike, Harbor will generate an individual OCI artifact for the produced spawn. This artifact will be attached to an accessory that I mentioned earlier. We call it an accessory in Harbor dictionary to the main image. So consequently, Harbor will be able to virtualize the relation and distribute them as a cohesive unit. And let me try to start a demo of a spawn. So for today, I'm trying to create a project. And then I'm trying to push an image to my project. So after I, you could see the image of the Paris project. And then you will see there are two more buttons here. And spawn generation and stop generation. So here, let's try to generate spawn for engines. And the status changes to Q. And let's wait for several seconds. And you could see there will be one more OCI object be attached to the subject engine. And the type is Harbor door as well. And there is a link for you to see the spawn details after click. It will jump to the degree. You can see all the package information like name, version and license. And we do have the pagination. So you can view all the package information then in this website. And beside that, you can download the whole JSON file for you to distribute them to others. You can see the format is SPDX. And it's generated by Trevi and all the other package information here. So, and beside that, we do have one more option for you to auto-generate as bomb on push. That means when you push a new image into Harbor, Harbor will auto-generate as bomb and be attached to as a kind of accessory to your subject manifest. And after that, let me try to replicate my image with the spawn file to another Harbor. So after the replication has communicated successfully, you can see in the target project in the target Harbor, you can see there are two objects. One is engines and the other one is the as bomb file. And you do not need to regenerate the as bomb again. In the target Harbor, you can see the details directly after the replication successfully. Yeah. This is the demo for as bomb and about the future. So what do we plan to do? We have committed to diving deeper into artifact security and essentially in the realm of as bomb. Since we already support as bomb, our next step is to optimize its usage to accelerate the CVS scanning performance. Lime is leveraging as bomb to streamline the scanning process as it will need to put the entire artifact but the as bomb file. And additionally, we are exploring integrating as bomb with the Harbor security Harbor to provide a comprehensive global security overview. By the way, we wanted to define some policy around the packaging information a similar way as CV scanning like if your image has some critical package, then you can define a rule to block that image to be put. And looking ahead, we are considering expanding support for multiple scanners. So currently it is singleton system but by supporting multiple scanner, each one can essentially complete its tasks. So then Harbor can consolidate all the results for the artifact ensuring comprehensive coverage analysis. So for the more, we are enhancing the audit log with more detailed information. This will provide administrators with great visibility and insight into Harbor activities. This is all part of what we are doing and what we will do. So again, we are seeking cooperation so if you guys have any interest on Harbor, no matter it is PR issues box or documentation or if you get using Harbor operator, like LIMSAN or Harbor Health, join me live through these weeks. Thank you. I think we have some time for questions. So there are some microphones if you can. Yes, we can. We do have a repeater rule. So you can define the rules, match any repository or tag. Yes, yes. Hello. I have a question regarding deployment security because we've recently started using Harbor particularly for the security reason. As a pull through cache for instance for Docker Hub or Quay or something like that. And when you use deployment security you kind of want to prevent that you pull images that have critical vulnerabilities for instance. But when you use this with a pull through cache when the image is not yet present in Harbor the scan happens synchronously. The first scan happens synchronously so even if your image has critical vulnerabilities it will end up being deployed and then any subsequent pull will fail of course but it's already deployed. There is an issue open for this and I also asked about it. Is there any outlook that this becomes configurable? Yes, the scanning performance is a problem so that's why I mentioned earlier that we want to leverage the SBOM to accelerate image scanning because the scanner should not pull the entire object just pull the SBOM file in KB. So if you are significant in increasing the performance. Okay, but will you make it configurable that this first pull will fail in this case so that it needs to wait for the scan to complete? Yes, you have to wait. So currently you have to wait because from the security perspective we do not know whether your image has critical safety or not. So if we do not know it, so we block it. So you basically want to have an image that not have been scanned not be able to get pulled? Yes, at least it should wait to serve the image to the puller until it is scanned and that it's basically saved but currently it just serves it anyway. And then it blocks it. And then after that it cannot be pulled anymore but it's deployed already and this only happens on an image that's not yet present. So it sounds like before I know it you cannot pull it. We need to take it as a feature request then. Firstly, awesome work for implementing the referrers API. We've been waiting for that for a long time. And on the topic of is storing other artifacts in OCI repositories like the NPM packages a game changer from my opinion? Yes, I think it is. But I have a question around the Sbom storage implementation in Harbour. So can I store more than one Sbom per artifact? Yes, you can. And it looked like the Sbom format of choice that you went with was SPDX. Is that the default? Yes, currently we do only support SPDX. But in the future plan we do have an option for the system I mean to select whether it is SPDX or Cyclone DX. And may I ask what was the decision that drove you to use SPDX over Cyclone DX or any of the other? Based on the discussion with the tribute team. Fair enough. Thank you. Anyone else? Any more questions? No? Thank you. Thank you everyone.