Add password=password parameter into clair_config/config.yaml PostgreSQL connection configuration.
I also recommend changing the default postgres:latest docker image by arminc/clair-db which already contains the CVE database. Otherwise, we need to wait roughly 30 minutes before the database gets downloaded.
Let's start our local Clair:
Analyzing a docker image in a few steps
In the rest of the post, we use the docker registry V2 built in the previous article with the same pseudo domain name registry.mydomain.com and same Basic Auth credentials admin:admin123 .
First, we need to have an image in our registry to be able to perform an analysis of it.
So let’s pick up, for example, a debian:9.5 image and push it to our registry.
With the image in the registry, let’s get the HTTP URLs of its layers in tar format. To do that, we need to get its manifests:
in a JSON response, a field fsLayers contains all the image layers identified by blobSums.
Each docker image is always composed by one or more empty layers generated by commands from Dockerfile like CMD, EXPOSE etc. which don't modify the content of the image, so we don't need to scan them.
Because these layers are empty they always have the same blobSum:
Therefore we can easily identify them and exclude them from Clair analysis.
Knowing that we want to analyze only the second layer with blobSum sha256:05d1a5232b461a4b35424129580054caa878cd56f100e34282510bd4b4082e4d to get its content, we need to call a different API endpoint:
In response, we get a tar file representing the delta of the layer. That is what we need to provide Clair to let it do its analysis.
Now let’s tell Clair to analyze our docker image composed by only one "scannable" layer.
To do that we call the API POST https://localhost:6060/v1/layers which requires a few parameters:
Name - we can use blobSum of a layer. Here we need to keep in mind that the name field has to be unique, that means we have to avoid pushing empty layers as they have the same blobSum. That’s also a reason why we decided to exclude it from the analysis.
Path - URL to tar file of a layer
Headers - has to contain Authorization header to make Clair able to reach Docker Registry. In our case, it’s Basic Auth. (We can generate a Basic Auth token like this: echo -n "admin:admin123" | base64)
Format - Clair supports both Docker and Rkt formats of container images.
ParentName - this field is optional and has to be used if we want to analyze a docker image with more than one layer. In such case we need to push these layers in the right order by referencing its parent layer; otherwise, Clair will not be able to provide us with results of the entire docker image.
Let Clair do its magic:
When finished, we are immediately able to get a result of found vulnerabilities in the layer by calling the endpoint:
In response, we get a list of all features present in a filesystem which could indicate a vulnerability.
One of the features in our tested debian:9.5 docker image is for example systemd where Clair found some vulnerabilities listed below:
What we must pay attention to are 2 fields:
Severity - telling you how critical is the vulnerability
FixedBy - telling you there is a newer version of a feature which fixes the vulnerability. The field doesn’t exist if there isn’t a fix yet.
We have learned how to use Clair without using any third-party client which helped us to understand how Clair works.
Now with this in mind, we can look at popular third-party clients like klar , clairctl , reg and many others that simplify the work with Clair. With them, you don’t need to care about layers as you provide only a docker image name and the client does the rest for you.
So what was the reason for writing this article you might ask? Well, let me cite one paragraph from official Clair documentation: "Clair can be integrated directly into a container registry such that the registry is responsible for interacting with Clair on behalf of the user. This type of setup avoids the manual scanning of images and creates a sensible location to which Clair's vulnerability notifications can be propagated. The registry can also be used for authorization to avoid sharing vulnerability information about images to which one might not have access." And that's something that we will look at in next article.
Read more about NearForm’s services and how we assist businesses in product design and modern application development or contact us to discuss how we can help you accelerate your projects using modern tools, processes and platforms. MILKOVÍ
Insight, imagination and expertly engineered solutions to accelerate and sustain progress.