Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 22 Sep 2020

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Intro: Harbor - Enterprise Cloud Native Artifact Registry - Alex Xu & Steven Ren, VMware

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Intro: Harbor - Enterprise Cloud Native Artifact Registry - Alex Xu & Steven Ren, VMware

As container technology becomes widely adopted in the industry, how to manage containerized applications poses new challenges to platform engineers. One of the challenges is to securely and efficiently manage containerized application packages with either container image or Helm Chart format. Project Harbor is an open-source trusted cloud native registry project that stores, manages, signs, and scans content, thus resolving common image or Helm Chart management challenges. In this presentation, we will focus on the management of container images and Helm Charts through Harbor. We will review and provide solutions to the challenges faced by organizations, including RBAC (Role-Based Access Control), content replication, pluggable vulnerability scanning, large scale content distribution, content trust (notary), webhook, tag retention, online GC and DevOps integrations, etc.. Real-world use cases will be discussed in the session. Of course, fantastic demos will be shown to let you easily understand the related use cases.

https://sched.co/Zewj

A

Good morning, good afternoon or good evening, depending on where you are um we're very happy that you can attend this session, and today, myself and my co-presenter will talk a little bit about the harper project. So this is supposed to be an introductory session.

A

um It's gonna be fairly light and we'll give a sort of a high level overview of the hardware registry, and you know what it is why you might need it and the current status of the project uh a couple. Some of the things that we worked on for the last couple releases and then there's also a deep dive session, where our engineers will go into more details on some of the specific features that are coming out.

A

um 2.1 release the upcoming release, and then we have a demo prepared for you today as well and we'll leave the last time. 10 minutes per q, a so a quick introduction. I'm alex chu, I'm a product manager in the cloud native team at vmware leaking that harbor effort. So I'm trying to responsible for trying to understand the requirements around the registry, driving the roadmap, collecting feedback and making sure we're constantly improving and seeing sustained growth within the community and with me today is my co-presenter steven grim, stephen.

B

Hi everyone nice to meet you and welcome, come to join our harboring stock session. My name is steven, so I'm working for harbor as an engineer manager in winter, so I'm mainly responsible for development feature and management release.

B

In the same time, in vmware I also mentioned the uh telugu navigation.

A

Product all right, thank you steven. um So what is harper well harvard is a trusted cloud native registry that can store, sign and scan content, and so it's the registry is basically just a place to hold host and manage your artifacts.

A

And so when we started this project, we set out to build an on-prem registry leveraging the docker distribution, which was the de facto standard for storing container images at the time. But we also wanted to address on the issues that we came across while using docker hub and some of the other alternatives and then over time, we've added more and more services and features to it.

A

Like lifecycle management features, security features like scanning and signing, and so our missions right now is still to be the best cloud native registry for kubernetes, uh and we started support for docker images and then expanded to helm, charts in the 1.6 release and now with oci, which is the main theme for the 2.0 release that I'll talk about in a little bit. You can support any oci compatible.

A

Artifacts, so uh this is a quick timeline of the project. The biggest announcement this time around is that we have officially reached graduated status in cncf and becomes the 11th project in cnc to do so, along with projects like kubernetes container d, helm, onboard prometheus, and so you can see that we started this journey back in 2014.

A

So we put a lot of work and attention into it and so we're very happy and we're very proud of what we've accomplished, but we could not have done this without everyone in the community, including all of you guys on the call today and the community plays a huge role in helping us understand, test, giving feedback and sort of driving the road map with us.

A

So we're very appreciative of everyone's contribution here and in the project. Reaching graduated status means that you know it's hit a certain level of maturity, but it's really the potential in the road map that drives this decision.

A

So this is a quick overview of the various pieces or capabilities that make up hardware and we'll just go over a couple of these real quick first thing is access control. You can use localdb, ldap or oidc to connect to hardware and manage your users and their permissions into hardware projects if you're not familiar with hardware projects. Think of it as like the name space, that's a unique tendency and has its own set of repositories and images that are completely isolated from each other.

A

We also have robot accounts for service accounts, cicd type of scenarios to automate the pushing and pulling of images, and you can configure uh replications referring to the ability to configure push-based or pull-based replication policies to and from other registries. So that could be a harper.

A

It could also be something like docker hub or quay or any of the other popular sas registries like gcr, hdr ecr, and then we have the ability to scan images from within harbor leveraging popular image standards like clear, encore, trivia by security and a couple of others, and then, once you have those vulnerabilities, the list of vulnerabilities discovered from the image scans. You can actually create security policies around these, so you can create a process that says: hey, disallow, any kind of image pulling on images with certain vulnerabilities.

A

You can also sign images leveraging docker content, trust which comes with harper and likewise create image form policies based on these on the signature. So, for example, you can say something like prevent any unsigned image from being deployed.

A

We also support managing home charts, so previously this was done in the third party extension that we added to that. We had added called uh charm museum, but with the 2.0, you can now push these directly to the registry and they sit alongside your container images.

A

So we have a single web console that you can. You know, do everything for managing your artifacts, your users, your policies, running special tasks like arch collection and everything you can do on ui. You can do it through an api and finally, we have a couple of deployments with harper. So there's a doc compose format you can also deploy harvard as a kubernetes cluster. Using our hum chart and bosch is another um container orchestrator that that's used very heavily in cloud foundry.

A

So this is an overview of the harper latest harper 2.0 architecture. Makeup. You can see that we're still based around the docker distribution, still a crucial piece of the harbor um and going from top. You know we have a bunch of clients, you can interact with harper through dr cli kublet, helm, client and, since 2.0 will see support for all these additional cloud-native artifact types. Now there are other clients, the different artifact authors that build for interacting with the registry.

A

So, for example, auras is one such client. That's been that's very popular for pushing a lot of generic oci artifacts like lci indexes. You can also push home, charts and coach open policy agents.

A

um Chart museum is still here, so you can post them and chime these in as well as in the top distribution, but we do have plans to deprecate to our museum in the future and then on the on the right-hand side.

A

We have a list of supported scanners scanners are added in out of tree fashion to harvard for plugable interrogation services framework, and you know we talked a lot about this in the 1.10 release, but we do have some changes related to the default scanner that I'll talk about in a later slide and finally, we've expanded a list of reputation targets, so you can replicate, announced just to harvard and docker hub, but a lot of the other sas registries as well- and you can replicate you know all these other artifacts now beyond, just container images and helm charts.

A

But obviously that also depends on the supportability of these artifacts on the target registry.

A

So if you've seen the cncf announcement and the release block around harper, 2.0 harbor 2.0 was all about you know harvard becoming ocean compliant registry, and so we should talk a little bit about what it means. What oci is before we talk about what it means for harvard to be in those night compatible registry or those that complying was like capable um so found.

A

This picture we start with docker on the left hand, side or the docker distribution to be more specific and the docker distribution is just essentially some content store for storing your docker images and so harbor as a registry uh built around docker distribution is just some http api, backed by that content, store and so up until very recently, before the 2.0, the only artifacts that you can push to harvard and manage on hardware or container images.

A

Yes, you can push hum charts but, like we said earlier, those were managed through char museum separately from the images and they didn't get the same set of features like tag retention, tag, availability that container images had and so oci.

A

The open container initiative is a group that came along to define specifications around format, runtime and distribution, uh so that a broader set of cloud native artifacts can get the same features as container images, and I wanted the distribution to be able to deliver a registry that is secure, cross-layered or layered and cross-serviceable, and so it took the docker, the 2.2 image spec as a starting point to create its own specifications, around image format and image runtime.

A

And so what this picture is attempting to capture is a little bit of that process or that history, where oci formalize.

B

A

uh Around uh image, format and image distribution and that work was merged back into the doc distribution, so that it fully supports ocean images and so docker distribution in turn. Harbor can now support hosting all these other cloud native artifacts that we've heard so much about in these conferences, such as helm, charts, uh cnap, open policy agents singularity.

A

So the second icon here is supposed to be a clap on a scene app, what's known as a cloud native application bundle, it's another application deployment oriented artifact. It's worked on by the guys over.

A

A

So being able to host dr manifest list is one of the things that came out. This support for oci the docker manifest list is something that has existed for a while, but was was previously unsupported in harper, and the manifest list is essentially just the packaging of manifests.

A

um As you can see in this picture, we start with the manifest list, which is itself a shot digest and it's acting as a pointer to all these other images, they're each built for specific architecture, and so it's holding these together in some way and that's what allows you to use the same image name um for all these different images built for different architectures, and so just try to keep this in the back of your head that there is this index structure called an oci index and we'll come back to this later in the.

A

Demo, and so docker hub is actually a really good example of something that is oci and compliant, and probably the first uh registry that's also compliant, and it can fully handle the docker manifest list that we just talked about. In fact, pretty much all the official images that you see on docker hub today are using the manifest list allowing for multiple platforms to be supported using the same image name.

A

Image tag combination, so here shown here, is the busy box image with tag latest, and you can see that it's referenced in multiple shot, digests for different architectures, so you have linux, you have arm, you have mips and you even have different variants of these architectures, and so, when you do a docker pull busy box from docker hub today, it will actually fetch the version of that image that matches your client.

A

So unless you're pointed specifically by digest, if you pull by tag, docker hub will responsibly fetch the right version of that image.

A

And so that's the experience that we wanted to deliver with hardware as well that users can push and pull manifest lists that they can manage these as a whole, but also manage the images within individually. And so that's also just one use of the nose index. This multi architecture image on docker help that we just looked at, but there are other artifacts that are leveraging this that are shown here and so.

B

Here we're looking at.

A

A project within hardware we're looking at a specific repository within that project, and you can see that we have a container image, a helm, chart uh cloud native application bundle and another docker image on the same projects uh recognized by their logo on the left hand, side, and so we put this here to sort of draw contrast with the one point x version harper, where you only have container images nothing else. But now you have all these other artifacts that you can manage in the same project.

A

So that's really the biggest piece for the 2.0 release. Now the other work we did for 2.0 was replacing claire image scanner with trivi, which is another open source image. Scanner by a company called aqua security and clear, has been our default scanner and since probably going back the first version of hardware, but we started looking at other scanners because the users have been asking us, you know I've set up such and such scanner I've paid for such-and-such scanner. Can I get that to work with harper?

A

And so you know in the previous 1.10 version, we had done a lot of work to sort of open up those partnerships with different image scanners through our plugable interrogation services framework, but this is sort of taking things one step further with regard to the embedded default image, hyperscanner and so very, very simply. We landed on trivia because it's simple, it's comprehensive. It's fast and it's accurate.

A

It's also easier to set up. There's no need to manage a db instance separately. It runs in docker, reverse mode. Trivia also has a wider coverage just getting different operating systems and application dependency managers.

A

A lot of which are listed here, but there are more and we found trinity to just be superior in conducting deeper scans and capturing more vulnerabilities across all the different operating systems that we've tested, including db and ubuntu suzy photon.

A

So please check them out if you haven't- and I believe they have some sessions at this conference as well.

A

So that's 2.0 in a nutshell, and I just wanted to spend a quick few minutes on giving a preview of 2.1 upcoming release.

A

First, one I'll talk about is called proxy cache, which is the ability for hardware to act as a pull through cache for another remote registry, and we can call that registry the target or the upstream, whatever mode, and so this is useful in situations where you have docker nodes that either have limited connectivity or no connectivity to that target registry, uh and it could be any number of reasons or it could be security or compliance reasons, or it could just be pure connectivity issues and eliminate regress options, and so docker hub is a really great example, and that was the case that was brought to us.

A

That was the most often raised to us. Docker hub is a registry where your docker clients from all the world are attempting to pull images from. If you're. If you pull too fast or you pull too frequently, then your connection gets throttled or you might even get ipv, and so hardware is a proxy cache. That's meant to address this very problem, and in this case it means that hardware will serve.

A

So if you have a hardware deployed, it will service the middleman to pull the images from the remote registry that you're trying to hit cache it locally and then serve it to you, and so it's much faster and it minimizes traversals over the network and prevents you from getting out of your bank and the way to do this is to create a project in harbor.

A

uh It's if you're familiar with how you create project hardware, it's the same process except there's an option to enable it as a proxy project which requires you to enter the target registry, endpoint and the credentials.

A

And so when you want to do a docker port from that remote registry, you can instead do a docker poll from the proxy project. Instead, so you will have to modify your docker pokemon and your pod manifest to hit that proxy cache.

A

A

So I mean in the interest of time I'm gonna just give a one or two sentence summary of this. um I can't go into too much detail. You can you guys can learn about this in the deep dive, but essentially we're improving the garbage questions. So it's not blocking, so you can still push and pull and delete images while it's running. This is not the case right now, because the register is put into read-only mode and then we also have an integration with p2p providers like rupert kraken and alibaba dragonfly.

A

So there's going to be a way to sort of uh there's an action called preheating which moves the images from harbor uh to the ptp side, where it can be geo, distributed to hundreds or thousands of millions in a more effective way, efficient way, utilizing their ptp.

A

A

So last thing um you know: that's the 2.1 it's coming out end of august. uh Please give it a try and appreciate any feedback you have when it comes out. Just final word about the community. The community is doing really well and we appreciate everyone's contribution, whether it's raising requirements or fixing bugs submitting prs or doing code reviews, which is attending the community meetings and attending this creepy fun conference, for example.

A

So we're at 2l point fork, 12.4k stars and more than 200 contributors and lots of companies are using hardware or have partnerships with us.

A

All right, I'm gonna, let's even do the demo, because I think we're at almost 20 minutes. Sorry about that. It's even.

B

Okay: okay, thank you. Thanks for alex, let's share my screen.

B

I assume everyone can see my screen.

B

B

Yeah as alex uh introduced, so we have several major features. Give me interest with time I'm going to demonstrate the two major features from 2.0 and 2.1. So the first one is about the oci support. uh We provide it in 2.0, so as alex introduced so for the 2.0 we have introduced artifact support with this feature. We can not only manage the images and we can also manage hem, chart cinema bundle and other formats which follow the oci distribution.

B

Standard yeah: first, let's have a demonstration on the manifest list. As we know, manifest list is a feature that.

B

Which can store all kinds of different architecture? Images uh for a single uh repo, so um I will demo how to upload a manifest in through those steps. First, we need to create a manifest and toggle has provided a manifest command which allows you to create a manifest, and you need to specify the target url, as well as the images which belong to the manifest list. So here I have including two images, um so one is for the amd architecture, images and others for the arm architecture, images.

B

So once we have created manifest, we need to annotate uh those two separate images as different uh architecture.

B

So once this annotation is done and we can stock a manifest push.

B

To push to the.

B

B

Yeah so um once we have pushed to the hardware and we can check our ui look at what the ui functionality we have provided in harbor, so, as you can see, there's a hello world manifest uploaded and for the manifest there is a folder icon. You can click in and see what the inside the manifest images are. So.

B

Yeah, as you can see, the two images, one is the arm architect and I, the md 64.

B

Architect, yeah, so next, I'm going to demo is that um so with oci octet support. We can also upload the hem chart, as they know in hardware 2.x, the exporting user to upload ham, chat and manual chat to the chat museum.

B

So in hum3 there's an experiment: feature user can upload the hem charts to the osi compatible regist, and this is what I'm going to demo.

B

So, uh yes, the command shows that every time you need to set this experimental tag before you run any.

B

Commands for the expand for this experimental feature, as I have just showed, we have two hem charts and I tagged before the demo. So we can use helm, chart push to put this to harbor and watch once it is pushed and we can check on the ui.

B

In hubble portal and see the helm chart is uploaded and we have our ham icon also attached to with this artifact. So if you click into the thumb chart- and we can see all the additional information instructions harm chart, this is the themes that we have provided in chat, museum.

B

Yeah, so in the same time, you can also prove from harbor about the home that you have uploaded, and this is just the demo list. So.

B

Yeah so in the same time, we are not removing the uh chat museum feature because there's also existing from two users who cannot upload uh chats to the outside registry, still consuming chat museum. So we keep this feature in 2.0 and 2.1 and we hope that eventually we can remove this dependency and we can store charts all using ocr register.

B

The third I would like to demo is that the um cloud native application bundle scenario. So, as we know so in cloud native world, uh it's not just images right. We have chart, we have als, we have cnn bundle, we also have opa uh bundle, we have other like yama fail. We need to upload actually uh for the for the oci support and we can manage all those cloud device effects. This is demo that used the synaptic oci command to upload a cnm bundle to harbor, as we can see.

B

um uh This is the example of cinema bundle, json file, so once we have.

B

Done upload and we can see from the ui, there are two.

B

Two artifacts within the same bundle will be uploading as we can see that for this synapse icon and we can click in through this folder icon, we can see there's one image uploaded and also there's a file uploaded.

B

Yeah, let's quick quickly go through uh the power of the um oci formats. Is that so, besides any official formats, we can also upload our top file of folder, uh soon oauth command line to manage the diff other author artifacts.

B

Here I'm going to show you that I used os to upload a tar file.

B

So you can simply use the os push, giving a target.

B

Url and with the location of your current charges, current.js file and once you have uploaded- and you can also use os.

B

Yeah, I also upload our folder, so once we have located, we can check the ui portal and we have upload this artifact and we can also put it down to our machine. So I'm just changing to different directory and remove the previous download version and I've used pull command to pull the touches file.

B

And in fact, as we can see so when you pull the user artifact in, if your or us will uh automatically change the format you have uploaded before, so you will get a folder and you will get a party file.

B

Okay, as alex mentioned, so besides the pull and push so there are other features like scanning replication and tank retention. All those suction energy can work out very well with the new oc artefacts.

B

Yeah, I'm just showing the scanning works, um so I think.

B

Yeah with that, let's move into the prox cache feature from the plus cache. Actually, we are solving two problem. One probably is that when you have uh isolated environment, uh probably you can use. You just need to configure the hardware as your proxy to pull image from outside your isolated environment and then, however, caching, this pull the images for the first future use. So let me go directly to how the user can complete this. So first.

B

User need to create a registry endpoint. This reduce endpoint is tell the hotel harbor, where you would like to pull your images from so for this demo, I'm currently choosing a docker hub registration plan. As you can see in the previous list, we are almost swatting um as many replication, ridges and pond country support uh as possible.

B

So once you have configured this docker hub, which is in point, what you further need to do is that you need to create a policy cache project, so you create a project, and what you need to do is that you check this postcast feature and fill in the endpoint. You have just config and click.

B

B

Yeah once once this is done and you can see a new project is created and you can change to the command line to push images. So here, as you can see, I I have um yeah, I removed the previous download image and I will pull a new images um through this pause cache projects so.

B

Yeah, besides red is, I can also pull the mysql. I can also pull hello world. Whatever you have in your docker hub, you can pull it yeah. So once you have pulled it successfully, you can see a new repository is cached in harbor uh in this postcast project.

B

um Yeah, I think that's all my demo um we giving into the time and uh for the other features we have introduced. Please join our deep dive session, so we will have issues more about other features.