 Thank you everyone. Thank you for joining us today. My name is Yan. I'm currently a cloud native developer at VMware. I'm sort of leading the project Harbor right now. I'm responsible for driving the roadmap, maintaining code base, and collecting feedback. With me, Vadim. Yes, hello everyone. My name is Vadim. I'm not working for VMware, but we're working together with the Harbor on the Harbor. Welcome everyone. And we would like to give you an introduction to not introduction to Harbor, but an overview about Harbor. What's new? What's coming up next? Yes, thanks Vadim. During this session, we will cover introduction to Harbor, including its features, purpose, where we are right now, features, and demos. With the rapid growth of container adoption in recent years, managing cloud native artifacts has become a challenge for many enterprises. According to the CSF, the way container usage in production has seen a dramatic drop from 15 to 85. As developments get larger and cloud native adoption has become more mainstream, as registry is essential for managing all your cloud native assets. This is where Harbor comes in as a key gradient for a cloud native environment. Managing production containers can pose challenges, such as potential CVE policy consistency and registry access. You must know your policies, how they are deployed, and who has access to your registry for pulling and pushing images. And you must enforce compliance policy related to your artifacts. Most importantly, you must ensure that your artifacts are free of vulnerability and secure before deploying them to Kubernetes or any other container on time. So what is Harbor? Harbor is actually the open source registry. We built this project in 2014. Originally, the idea is just to add a UI to the open source distribution. We got a lot of good feedback from internally, so we decided to open source it and donate it to the CSF. And eventually, we graded from CSF at 2020. So we have learned that don't be afraid to start from small. We never changed our mission. That is to be the trusted cloud native repository for Kubernetes. So let's take a look at our core tenants. We offer multi-tenancy in two different models. Role-based access control allows for flexible models of defining users and their permissions, giving you the isolation at project level. Every project can be tailored to the needs of the individual user who will be using this project. And the core of Harbor is policy. We give your ability to create callers so that you cannot provide a project from being overused. You can also set retention policy, defining rules that govern how many artifacts of a given repository to return or for how long to return them. Additionally, we offer a new ability to ensure that stable images cannot be overwritten. We also have vulnerability policy where image cannot be proved if their layer is smaller, is equal or higher than the selected level of sovereignty. In terms of artifact distribution, we offer replication, allowing you to pull a push image from Harbor to another container registry. We also offer a proxy cache, allowing you to privacy and a cache image from a target and private registry, such as Dock Harp. In addition, we integrate key P2P capabilities of C&C project, like Dragonfly and Warwick Kerakken, into Harbor allow users to define policies around this action. Security and compliance are at the core of what we offer. We provide identity access management to what are the users from any identity provider you want, whether it is DAX, FDAP or anything else. For signing, you can use co-sign or another way to sign your image, or you have the ability to scan your images and verify the public disclose the CVE. And we have a CVE allow list, allowing you to set exceptions for certain CVEs that you do not have any solution for yet. Last, we offer extensionability, allow our users to deploy Harbor within their own infrastructure, and make it compatible with their existing investments. For example, if you are using a specific CACD tool, we can give you a web hook so that you can integrate with that tool. Additionally, we offer the rubber cost that allow for hard list configuration and running automated actions in your system. For the moment, we have a full REST API. I don't think you can do using the Harbor API. You can do it through the REST API. Let's take a closer look at the Harbor architecture. In the middle, the Harbor core is a collection of components that provide essential functionalities, such as project, artifact management, configuration, callers, and more. Under the Harbor core, there are several components, such as garbage collection, controller, log collector, integration with notary for signing, and distribution for pulling images. This service services can be individually scaled in a Kubernetes cluster. Harbor can be deployed using Docker compose, ARM chart, and operator. Harbor also offers three data access capabilities, key value store built on top of REST, local and remote store for storing artifacts, and a database for storing project data policies and access permissions. One of Harbor's key feeler is integration, allowing for replication and scanning capabilities. With replication, Harbor can define replication policies and interact with distribution services, such as Docker harb, Amazon ECR, Google GCR, and more. As for scanner, Harbor allows for protocol standard enabling different security companies to introduce their scanner to Harbor. For example, if your organization is using anchor, that could be the scanner for Harbor projects. Finally, Harbor provides the observability and tracing capability. It exposes key metrics that operator can use to monitor its real-time performance. Harbor also offers distributed tracing data using open telemetry, and that means you can expose the tracing data to a GAGR back on directly. So what do we have in the last two releases? The first is the job service monitor. It is really useful to keep an eye on the job service and control its operation. With the dashboard, you can view paths or stop the job execution. Plus, you can use the dashboard data to help you to make decision-like about scaling up or down your job service path, which gives you more control over your system resources. The best part is that everything is centralized. So you can control or monitor job service from a single and easy-to-use dashboard. Next is replication by Tron. So when you need to copy a large amount of data, there is a feature called copy by Tron. That can help. This feature splits into big blob into small pieces, which make it easier to copy them over network. This is especially helpful when the network connection is not very strong, like when you are working with the edge computing. By using this feature, you can increase the chances that the replication will work and the data will be copied correctly. To enable that, all you need to do is just click a button when you're creating the replication policy. Next is the feature on the latest release, that is the OCI 101 adoption. In the past, container registry were intended to store the container image only. With the introduction of OCI, container registers can store other artifacts like a swarm, signature, tags, or even videos. The OCI 101 goes even further and allows you to establish the relationships between artifacts. This is a compelling functionality that allows you to create structure like this. Now, hardware is not just a storage place for images, but a generic artifact storage that can also define relations between artifacts. Lately, we did some fundamental enhancement on the webhook to make it more useful and scalable. One of this is the ability to keep track of webhook history. That can be helpful for tracing and managing the webhook activity. Another improvement is the ability to debug the webhook jobs. That means when a webhook is triggered, logs are generated that can help identify and fix any issues that may raise. Finally, there is now an option to choose format of the job of the webhook for payload. Being able to choose the format can help ensure that the webhook data is compatible with receiving application. Now, in 2.8, we support soft design format and cloud events. This is the demo for OCI 101 adoption. In the demo, firstly, I will upload artifact. I will use the cosine client to sign this demo artifact. Now, we are trying to sign this demo artifact. After it succeeds, you can refresh the page to see the signature is attached to the demo artifact. Next, let's use the cosine to push S-bomb. Please note that we are using the experimental OCI 101 mode in cosine. After that, we can refresh the page. You will see the two attachments, the S-bomb and the signature alongside with the demo artifact. We can also use the cosine client to view the linkage between these artifacts. After the cosine trade command, you can see these two attachments. Finally, we can even give S-bomb its own signature using cosine. We will sign the S-bomb artifact. After that, you will see the signature of the S-bomb at the third level and with the demo artifact as a root. Now, there are three layers. Next, let's try to replicate these artifacts to another harbor named Harbor 2. That I have already added as a replication endpoint in Harbor 1. After we replicate the artifact to Harbor 2, you will see all the attachments will be replicated together. Now, we can go to the Harbor 2 to see whether there are three layers, the same as the Harbor 1. This is the demo for OCI 101. The next demo is the Job Service Dashboard. The Job Service Dashboard monitors three categories, the Job Queue, Schedules and Workers. The Job Queue displays the pending jobs in total. Schedules show all the crown configurations of the current harbor, and Workers are the business units responsible for distributing jobs. In the data grid below, you can view all the predefined jobs, like garbage collection, image scan, and replication. And switch to Schedule, you can see all the schedules in details. And Workers, each harbor core has one worker pool, and by default, there are 10 workers. All of them are current in adult status. Now, let's try to create a schedule for garbage collection and check it in the Job Service Dashboard. Now, we have three schedules right now. And we can pause all the schedules with the Job Service Dashboard, and then we can check it in the clean page to see the schedule has been paused. Now, let's try to execute a replication task and control and monitor it in the Job Service Dashboard. So now, we can see there are more than 15 penny jobs in the Queue, and all the 10 workers are become busy now. So we can also track the running jobs, the running logs of each replication task. So we have a lock button, you can see the running logs here. So now, let's try to pause the running replication and try to free all the workers. So since the replication is paused, the Job Service will not distribute any pending replication task. So we can resume the replication task again. So then, we will see all the 10 workers will be occupied again by the replication task. Yes. So now, the 10 workers are busy now. All of them are running the execution job. So this is a demo for Job Service Dashboard. Yeah. All right. So this have been features that are already part of 27 and 2828. So you can use them already now. Let's look at some other functionalities that exist in Harbor that already exist, but are not that known yet. And one of those features or functionalities is a new SAP project we have now in Harbor, which is a Terraform provider is now part of Harbor. It was initially developed by the company Bestseller and who donated the project to Harbor. So it's now under our rooftop and we maintain and extend the project. It's maintained by Florian Plampi from SNCF. And because the project went from Bestseller to Harbor, some folks from Palumi, Engendir, we decided it would be a good idea to have also a Palumi provider for Harbor. And now we also have a Palumi provider for Harbor. So this means that you could, well, I mean, the big advantage here is that you can use the old infrastructure as a code functionality that you normally use with your infrastructure. You can use it now to configure Harbor itself. And it's a really powerful functionality because you can do things this way that you cannot do with the UI or with the REST API in that easy, you know. So the most important part is if you would like to introduce a self-service functionality into your Harbor, so if you're kind of an ops team and you're maintaining a Harbor instance and you would like to, you know, make it possible for developers to self-service, request to projects, request to, you know, permissions for this, for that, you can do it in a self-service manner with, you know, Terraform or Palumi. There is a good opportunity, so if you would like to extend your GitOps workflows, you know, beyond your infrastructure, so you would like to extend the GitOps workflow to your application, this is also a great way to accomplish this, right? So we have now these two providers, Terraform and Palumi. And the good thing is if you're, you know, happened to use Terraform in the past, you know, with AWS or Azure, you know, things takes really, really long time, you know, so you can grab a coffee when something's happening. This is not the case for Harbor, you know, it takes a second, you know, until everything is complete, which is really a surprise, you know, when you run it. And it's really easy to understand, right? So it's like really simple understand, you can automate a lot of things, basically everything in Harbor with Terraform. Same goes to Palumi. This is a Palumi Python example. It's a straightforward Palumi example. You can, you know, you can write it in TypeScript, JavaScript, Java, Golang, whatever. It's a really simple way to automate your workflows. This is already available and you can use it already. And yeah, now I would like to show you a few things or explain you a few things that we are currently working on that will come into Harbor into nine and beyond. One of the things we're currently working on is this is part of the LFX program. So it's a Linux foundation, Menti program. One Menti is working on that. It's an official Harbor CLI. There are plenty of CLIs out there for Harbor, but we would like to, you know, consolidate it and bring it all together. And it will allow you basically to manage your Harbor instance from the CLI. You can do it, you know, from a CLI, you can do it from a CI CD, like all this typical crude operations. It's an ops friendly alternative to infrastructure as a code like Terraform Palumi. You can do it on the, on a CLI same way. Right. So this is what we are working on already. And this will, you know, hit Harbor in the next month. Next thing we are currently working on is the vulnerability dashboard. You know, right now, as you may know, there is a possibility to view vulnerabilities, but those vulnerabilities are attached to images. So if you want to know about vulnerabilities, you have to look into the image and then from there you dive into the vulnerabilities. And you would like to turn it around to see what vulnerabilities do we have and to which images are they attached or which images they affect. So we, you know, provide a vulnerability dashboard that allows the CISO and ops people to navigate vulnerabilities to see what is, what vulnerabilities are there and give you a better overview about the vulnerabilities. There is already an option to export vulnerabilities. So you can export vulnerabilities and you can import it somewhere else and do the analytics stuff. And, you know, we would like to have it also in Harbor. And this is what we're currently working on the spec. So it's forward. The next thing we are working on is the, the Harbor operator. You may know that there is already a Harbor operator in, in Harbor, but the purpose of the existing Harbor operator is mostly for installing Harbor and providing the initial configuration. And because it's not what, you know, people had in mind when they've been, you know, looking for operators, there have been quite a few operators in the community developed by different companies. You know, mitwalt is one, a code movers, giant swarms, like there are four or five operators in the market or on the community that do basically the same thing, right? So it allows you to administer and configure your Harbor instance and not just installing it, right? And so we try to be talking with all these contributors there and maintenance of those projects to try to bring it all together into one official Harbor operator. And this will be a great alternative for you, if you would like, you know, if Terraform, Pulumi or CLI is not your thing, and you would like to do it a cloud native or a Kubernetes native way, this is the way to go to use the operator, right? The next thing that, you know, I'm working on specifically is called Harbor Satellite. And this is a concept where you have a little registry running inside your cluster. And this registry as a satellite is connected to ground control and receives commands and images from ground control so that it can run on edge devices, right? So, and it also sustained connectivity issues, connectivity problems to your upstream registry. And this is something that, you know, allows you to add resilience to your to your cluster base, right? And you can use it as well as as a CDN. And this is how it looks like. It's, you know, very simple. We have a ground control that has, you know, the policies, the commands and the information, what images should be present in on the satellite and the satellite fetches the information. It's a very simple, it's not simple, but it's a, it's a single binary, you know, containing the satellite core, containing registry, containing the database, and it's basically can run inside the Kubernetes cluster, or it can even run outside the Kubernetes cluster. And there is also an admission controller for, for developers or, I mean, for, for the operators that allows the developer not, not know that there is a satellite installed, because like if you deploy something to the satellite, you need to, you know, point to a different registry, you know, and you don't want to instruct the developers when they want to deploy something that they should use a different registry, right, a local one. And so the admission controller will basically write the port information to point all the image requests to the local registry. So this is what we're currently working on. And if you would like to have a CDN, you just attach an ingress to it, you know, and then you have a CDN of your registry. So this is something we're currently working on. It's not yet in, in development, more in the planning phase. And if you would like to join the development effort here, you know, please talk to me and we can see what requirements you have. Speaking development effort, let's go to the next point, our community. So at the moment, we have 11 plus maintainers, you know, depends how you define active, right? So it is like more, more or less active 11 people, right? So this is not so small. We have five different organizations, mostly prominent VMware than ourselves. There's OVH, Giant Swarm, some cloud providers, Tencent. We have, I think, over 170 contributions per month, right? So it's of course, you know, back request, open issues, and also ad hoc contributions from people who see opportunities to improve the product. We are currently working on the operator side. So if you would like, and if you're using Harbor and if you would like to use operators, this is a good opportunity for you to join and the operator program and, you know, help shape the operators and the design of the operators. Same goes for the telephone provider. We have already a maintainer who is working actively on the telephone provider, but, you know, more is better. So if you would like to join a few questions about how we can contribute, how we can help, there's two ways. You can just go to the website, the community website, and you'll find a link to the Slack channel. You will also find a link to the Be Weekly community meeting that we have. So you can just join the community talk and explain who you are, and then we can see from there. You can also talk to Olin, the person here. So he is the community manager of Harbor, and he can also help you navigate you into Harbor. You can, we have some, yeah, we have some times for questions now, but if you have other questions and you need more time to discuss it, come later and visit us at the booth on the other side of the hall where all the CNCF projects are located. We are always there in the afternoon, so today afternoon at 14 and 30, and tomorrow from 12 o'clock, we are at the booth. We can come to us, talk to us, and we can discuss it. All right. Now we have some times for questions. Oh yeah, thank you very much. One question to the replication. Right now it's possible to define an attack to replicate the images to another registry, but it's not possible as far as I know, even not in the latest version, to define a label. No, it's possible to define a label, but it's not possible to use these labels, which we have defined on the images, to not delete the images at a scheduled cleanup. So will this come anyone in the future? So let me rephrase this. So this means if you attach immutability to your images, you cannot delete those images, right? Yeah. So this is a common problem we see quite often, and we need to find a way how to deal with it, because the definition of immutability is immutable, right? So we have to find a way how we can define something that's immutable and else we'll define something that is a bit immutable, or just temporarily immutable. Something like this, we need to find a way how this can be accomplished. So we received already a few requests from the community regarding this, because sometimes you also want to clean up your immutable images after some time. And so we've been thinking about discussing yesterday as well about having some policies on the immutability that will remove the immutability after some time. So maybe something like this. So we need to brainstorm about this concept, how this can be shaped in a product. Do you need there any help in the conception way? Definitely. Because we have a use case where we are developing our product in a private environment and shipping on releases to earn public registry, these images. And yeah, probably we can help with our use case. Yeah, definitely. Talk to us to see how we can brainstorm and shape the design. All right. Thank you for your time.