GitLab Protect Stage, 26 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Continuous GitLab Container Registry Scanning Planning Breakdown

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Hello, today, I'm going to be walking through the planning breakdown for this feature that.

A

We're going to be working on, hopefully in the next few releases called Continuous GitLab.

A

Container Registry Scanning for the latest tag.

A

This is a pretty big feature. It's also going to be a pretty impactful feature for our users, because we're shifting from.

A

A model where users have to manually, run or schedule runs for container scanning to a.

A

Model where they just run by default.

A

So to walk through the proposal here, the first thing that we're looking to introduce.

A

Is a toggle. It's, a pretty basic toggle to turn container scanning, either on or off for the MVC.

A

This can be a backend toggle, something in Rails or a feature flag, something in the.

A

Backend. We could also expose it in the UI if it's easier, but it's also ok, if it's a pretty basic.

A

Toggle. As long as a customer can contact support and have this turned off,. That will be enough.

A

For this first iteration.

A

What, this will look like in the UI is,. If we come to the Packages & Registries > Container.

A

Registry page, there will be this section up top for continuous container scanning.

A

You will be able to see if it is on or if it is off.

A

You will get a "more information" button that will link out to our docs and give you information.

A

On how to turn that on or off.

A

So again,, it is a very basic, minimal implementation for this first step.

A

The second requirement is,, when it's toggled on for a registry which we want to eventually.

A

Togle it on, by default for all the registries, we're going to scan for all vulnerabilities.

A

That are tagged with the "latest" tag.

A

We're not going to do all the tags yet because that introduces some more complexity in the.

A

Ui- and it also adds a little extra performance, overhead.

A

So we're going to start with just the "latest" image tag.

A

There are two scenarios that might trigger a scan..

A

One is if the user pushes a new container image up to the registry.

A

And, the second one is anytime. Our vulnerability database is updated.

A

The second, one has the potential to cause some performance implications, because we're.

A

Essentially, going to have to go rescan all of the images for everybody for all of our.

A

Customers across GitLab.com every time our vulnerability database is updated.

A

For that reason it is important that we find a way to run these scans in a very performant.

A

And cost-efficient, manner.

A

We don't want this to be something that causes major performance problems or increases the.

A

Costs of hosting GitLab.com in a sizable way.

A

This has to be something that happens very fast,, very efficient, and very cost-effectively.

A

So, that's going to be one of the biggest challenges and tasks on the engineering side. For this.

A

Is finding a way to do this? Efficiently.

A

The second part of this is that we're actually not going to provide any customization of.

A

The container scanning job for this first iteration.

A

And, if we look at our variables that we provide for container scanning today,, you'll notice,.

A

That they're very centered around identifying which image needs to be scanned.

A

So we have things like CS_ANALYZER_IMAGE,, CS_APPLICATION_TAG,, CS_APPLICATION_REPOSITORY,,.

A

Connection parameters for connecting to the registry, DOCKER_IMAGE as well.

A

So for all of these, we can assume that we're using our latest container scanning analyzer.

A

Image. We're already connected to our registry, because it's our own registry.

A

We, already know which image we want to scan.

A

We, don't need to worry about the username or password or anything like that.

A

There are some parameters in here that might be useful to allow for configuration later.

A

On,, but for now we're just going to go with the default values for everything and we can.

A

Add customization in a future iteration.

A

Once, that's done,. Users need a way to view the vulnerabilities that come out from that.

A

Scan, so we're planning to introduce a banner on that container scanning page.

A

That will look something like this.

A

We actually have a couple mocks, but this is the one we're actually going to go. With.

A

It has a little info icon to let you know that it runs against the "latest" tag. Only.

A

And it shows the number of criticals, the number of highs, and actually,. Ideally, it.

A

Would show x, number of "other" vulnerabilities. Looks, like this mock, isn't quite perfect,, but basically the same sort of setup. That.

A

We have on our merge request, page where we show the number of criticals, the number of.

A

Highs, and the number of others, how long ago it was detected, and then we have a link.

A

Out to view those vulnerabilities and the same thing for dependencies.

A

For vulnerabilities,: we have that at the project and the group level,, so we're going to be.

A

Putting those in a new tab on the Vulnerability Report page in a new tab called "Container.

A

Registry vulnerabilities".

A

For, the most part. This is similar to the other tabs; although, you'll notice. The filters.

A

Here include a filter for "image", "severity", and "status".

A

We, don't need to filter by "tool" because there is just one tool at the moment. So there.

A

Is no point in including that filter.

A

Just to show a couple, other images here in the mocks you'll be able to come in and search.

A

For a specific image and filter down to just that image, if you wanted to do so.

A

A couple examples of what this might look like for vulnerability details I'm not too.

A

Particular on what this looks like as long as we get some good information in there, we.

A

Should be good for the first iteration.

A

Then, lastly, would be the dependency list page.

A

So here we would be introducing tabs into this page,, putting everything that is there.

A

Now, underneath the "Development dependencies" tab and then we would be introducing a new.

A

Tab for "Container registry dependencies".

A

That's, really what we've got planned for this epic.

A

It's? Definitely a large one. To make it more iiterative,. We could potentially release just the vulnerability report piece.

A

And introduce hte dependency list piece later on.

A

Regardless we've got to find a way to run these scans efficiently, which is likely I.

A

Assume to be the biggest engineering, task.

A

In any case,. Let me know if you have any questions for this feature.

A

I'm looking forward to moving it on to the refinement, phase.