How to use Harbor to scan Docker images for vulnerabilities

Make sure you're not deploying containers based on vulnerable images by scanning those images with Harbor.

How to use Harbor to scan Docker images for vulnerabilities Make sure you're not deploying containers based on vulnerable images by scanning those images with Harbor.

Containers have become crucial to so many businesses. With good reason. They enable a flexibility and agility the standard servers and services cannot achieve. However, of late it has become clear that containers do pose a certain problem. Said problem is the security of the images used to deploy containers. Unless you are building your own images, you cannot know, with 100% certainty, that what you are using is free from vulnerabilities.

Or can you?

Actually, there is a way to scan images for vulnerabilities. That way is with Harbor. Harbor is an on-premises Docker registry that, when built with Clair support, allows you to scan your pushed images for known vulnerabilities. This should be considered a must-have for companies that rely on containers.

SEE: Windows 10 security: A guide for business leaders (TechRepublic Premium)

But how do you use Harbor to scan those images? Let me show you.

What you need

Most importantly, you'll need Harbor up and running (with Clair support). 

NEED LINK TO "How to Install Harbor on Ubuntu 18.04" (OR WHATEVER THE TITLE WINDS UP BEING).

You will also need images to push to the Harbor server and a user account on the Harbor server. Other than that, not much else.

Certificates

If you plan on pushing images from machines on your network (that aren't your Harbor server), you need to copy the certificates from the Harbor server to the clients. If you followed the Harbor installation how-to, you might be using self-signed certificates. I'm going to assume that is the case. And so … here's how to copy those certificates from the server to the client:

  1. Secure shell into (or log into the console of) the Harbor server.
  2. Gain root access with the command sudo -s.
  3. Change into the certificate directory with the command cd /etc/docker/certs.d/SERVER_IP (Where SERVER_IP is the IP address of your server).
  4. Copy the ca.cert key to the client with the command scp ca.cert USER@CLIENT_IP:/home/USER (Where USER is a username on the client machine and CLIENT_IP is the IP address of the client machine).
  5. Copy the ca.crt key to the client with the command scp ca.crt USER@CLIENT_IP:/home/USER (Where USER is a username on the client machine and CLIENT_IP is the IP address of the client machine).
  6. Copy the ca.key key the client with the command scp ca.key USER@CLIENT_IP:/home/USER (Where USER is a username on the client machine and CLIENT_IP is the IP address of the client machine).
  7. SSH to the client machine with the command ssh USER@CLIENT_IP (Where USER is a username on the client machine and CLIENT_IP is the IP address of the client machine).
  8. Create the new certificate directory with the command sudo mkdir -p /etc/docker/certs.d/SERVER_IP (Where SERVER_IP is the IP address of the Harbor server).
  9. Copy the files with the command sudo cp ca.* /etc/docker/certs.d/SERVER_IP (Where SERVER_IP is the IP address of the Harbor server).

Your client should now be capable of logging into the Harbor repository and pushing images.

Tagging images

Before you push an image from the client to the server, the image must first be tagged. Let's say you have the official Ubuntu image and you want to tag it with a specific developer name. To tag this such that it can be pushed to the Harbor registry, the tag command would be:

docker tag ubuntu SERVER_IP/PROJECT_NAME/ubuntu:DEVNAME

Where:

  • SERVER_IP is the IP address of the Harbor server.
  • PROJECT_NAME is the name of the Project on the Harbor server.
  • DEVNAME: is the name of the developer you want to tag.

So the command could look like:

docker tag ubuntu 192.168.1.75/test/ubuntu:jack

Once you tag the image, you are ready to push it.

Pushing an image

First you must log into the registry on the Harbor server. To do that issue the command:

docker login SERVER_IP

Where SERVER_IP is the IP address of the Harbor server. You will be prompted for the username and password of the user on the Harbor server. After logging in, you can then push the image with the command:

docker push SERVER_IP/PROJECT_NAME/ubuntu:DEVNAME

Where:

  • SERVER_IP is the IP address of the Harbor server.
  • PROJECT_NAME is the name of the Project on the Harbor server.
  • DEVNAME: is the name of the developer you want to tag.

Sticking with our same example, that command would look like:

docker push 192.168.1.75/test/ubuntu:jack

Once the push completes, you ready to scan the image for vulnerabilities.

Scanning an image

Log into your Harbor registry and go to the project housing the newly-pushed image. You should see the image listed (Figure A).

imagescana.jpg

Figure A: Our newly-pushed image is ready for scanning.

Click the new image and, in the resulting window (Figure B), click the checkbox associated with the image tag. Once selected, click the SCAN button to initiate the scan.

imagescanb.jpg

Figure B: Our tagged image for scanning.

When the scan completes, you should see a bar representing the scan results. Hover your cursor over that bar to view the report (Figure C).

imagescanc.jpg

Figure C: Vulnerability report of the official Ubuntu image.

If you click on the tag name, you will see the full report, which presents complete results, including the CVE for each vulnerability (Figure D).

imagescand.jpg

Figure D: The full report for the official Ubuntu image.

Scroll through the entire report to view any/all vulnerabilities. If you find the image contains either too many total vulnerabilities or enough Medium or High vulnerabilities, I suggest not using that particular image. But it's important to scan through those vulnerabilities and make the call yourself.

Safe harbor

In this rising tide of container vulnerabilities, you owe it to yourself and your company to seek safe Harbor by scanning images for vulnerabilities before you use them to deploy containers. After all, it's better to be safe … than catastrophically sorry.

Also see

dockerhero.jpg

Image: Docker