Trusting the Docker Images Your Code is Built On

We’ve written before about the benefits of using Docker in your development environments. You don’t have to write every image yourself, though! There are many existing images on DockerHub and elsewhere that can get you quickly up and running. But unless you enjoy terrifying your IT department, please don’t run off and use any and every image you find! Like any piece of software, there are security vulnerabilities and potential bad actors. But there are also ways to mitigate the risks of using Docker. We won’t cover things you should be considering with any Linux install or third party software in this article. But these are the most important questions you need to ask before using a new Docker image and how to find the answers.

Who made this?

When using a new Docker image, ask yourself: Was this written by a company or open source community with a reputation to maintain? What are the authors’ goals? Do they have enough resources to keep their images up to date and respond to issues filed? A good indicator that authors are trustworthy on DockerHub is whether the image has been flagged as an Official Image or is from a Verified Publisher. Even if you’re using images with these tags or similar ones from other registries, it’s still up to you to decide whether you trust the source of this image. But without them, it’s worth taking extra time to verify the identity, motivation, and capabilities of the authors.

Finally, do they provide the source code? In this case, that would be Dockerfiles and Docker Compose files as well as any programs or scripts they’ve added. Depending on your comfort with the company or person involved, you may not find this necessary, but it certainly is a good sign to see they are happy to freely share what they’ve built.

What’s in it?

If you have access to the source code, you can build the image yourself and know what’s in it and how it works. But what if you don’t have access to that? There are some commands you can run locally to take a look.

• docker inspect will give you some of the information about the container, including any labels that the author has decided to add with what they think is relevant information.
• docker manifest will give you the generated hash values for the images this image was built from
• docker history will show the commands recently run on this image or container
• docker top will show the currently running processes in your container

It’s also best to start with the smallest base images possible. If, for example, you don’t need to use Python, skip using containers that have Python installed at all. If the code isn’t there, the vulnerabilities aren’t either.

Image authors can also push new versions of images to the same tag. If you’re using tags, use the most descriptive tag available to reduce the chance you’ll have changes in your build environment. To use Python as an example again, prefer tags that have the version and the OS listed, python:3.8-alpine3.12, over the simple tag alone, python. To know with absolute certainty what image you’re using, use a SHA instead of a tag. A SHA is generated hash value that is unique to every image, even if an author pushes a new image to the same tag. Many authors use a :latest tag, for instance. The image you pull will change every time the author pushes a new version to that tag. Using a SHA also protects you from unknowingly pulling images with malicious code if the author pushes new images to published tags for less honest reasons.

Okay, but what’s really in it?

There’s close to a full operating system in many images. That’s a lot of code and information to parse. Probably far more than you’re going to want to look at or want to know about. There are tools to test for best practices, common vulnerabilities, and malicious content or processes. You’ll see a Docker Certified flag on images on Docker Hub to note that the authors have done all of these tests before publishing. On other registries, look for similar proof that the authors are routinely ensuring their images are as stable and secure as possible.

However, with the reality of zero day bugs and the natural aging of code, it still makes sense for you to run tools like clair or use paid vulnerability analysis services. These tools can be set up in your CI pipeline to scan images for the latest known vulnerabilities every time you use them.

Is this what I think it is?

To ensure that the container you’re pulling down is the same as what the registry says it is, you can enable Docker Content Trust. This restricts you to using only images with signed tags or the full SHA id as described above. Trusts are applied to individual tags, not to the entire image repository. So you may find that awesomeImage:v1 is signed, but awesomeImage:latest is not.

What is it running on?

Like a virtual machine, the hardware you run your containers on needs to keep itself safe. Keep your containers in their own namespace, restrict how much a container can use of any resource, don’t give a container sensitive information unless absolutely necessary, and never give a container more privileges than it needs to get its job done. This is where your IT department is your friend. They likely already have processes and procedures written to handle all of these concerns from running virtual machines.

Conclusion

Like any good tool, Docker comes with risks alongside the rewards. But you can avoid collateral damage by asking what the risks are and putting safeguards in place before you begin. If you have any questions, or see anything we missed here, we’d love to chat!

And if you have questions about an embedded project you’re working on, Dojo Five can help you with all aspects of your devops for embedded journey! We are always happy to hear about cool projects or interesting problems to solve, so don’t hesitate to reach out and chat with us on LinkedIn or through email!