When it comes to security with containers, specifically container images, a lot can go wrong.
One of the latest State of Kubernetes and Container Security reports by Red Hat found that:
- 24% of serious container security issues were vulnerabilities that could be remediated
- Almost 70% were misconfigurations
- 27% were runtime security incidents
When you look at the stats above, it can get scary. Especially for an organization that may be thinking about moving to containerizing workloads. Seeing the numbers above, a CIO, CISO, and CTO wouldn’t know if containerization was the right call.
Luckily, as an engineer, you can help make that decision.
In this blog post, you’ll learn about why you want to secure container images and how you can get started with it today.
Once a container image, like a Docker image is built, you typically won’t go inside of it and see what’s what. For example, let’s say you build a Docker image, you won’t
exec into it and see what’s in each directory or what’s in the base image directories that you’re using to build the Docker image. The point is, engineers trust a lot of Docker images that are on Docker Hub without thinking about security.
When’s the last time you used an
ubuntu:latest Docker image or any other image and ran a security check on it? Do you know how it was built? What security practices were put in place to build it?
Defense in depth tells us that from a security perspective, we should trust to a certain extent, but still have the understanding that we, as engineers, need to confirm the technical pieces.
Two things that you want to avoid are:
- Getting called into the CISO’s or CTO’s office because your name was on a commit that pushed an image with security holes that were found
- Bring down an organization to a grinding halt because the base image, or any container image you’re using, had a security hole and it’s now spread across the entire application stack
Luckily, there are several great ways to avoid as much of security risks as possible. No one can ever dodge every security issue, but you can mitigate as much as you can.
Built right into the Docker CLI is an awesome security tool. Although it wasn’t built specifically for security, it’s a great tool to have in your tool belt.
The CLI tool is
docker image inspect
Docker image inspect gives you the ability to see a ton of detailed information about a Docker image, and one of the pieces of information is the container image hash. The container image hash can essentially tell you if anyone has altered the image and helps you confirm that the image is coming from the correct place.
Below is a screenshot of pulling a Docker image from Docker Hub called
When you run the
docker inspect adminturneddevops/gowebapi:latest command against the container image, you’ll notice that it’s the same
To confirm that the container image is coming from the appropriate place, which in this case is Docker Hub, you can see that the
sha256 matches with what’s on Docker Hub.
This allows you to confirm that you’re using the container image that you were expecting.
Another great command that’s part of the Docker CLI and powered by Snyk is
Snyk is a tool that’s used to check for container vulnerabilities from a pre-defined list of best practices. Docker and Snyk partnered to ensure that security is embedded natively into any containerized workload.
To use Snyk, you simply have to run the following command:
docker scan containerimage:containerversion
For example, let’s say you wanted to scan the
ubuntu:latest container image:
docker scan ubuntu:latest
You’d see an output similar to the screenshot below:
Scrolling down throughout all of the vulnerabilities, you’ll see a summary of the vulnerabilities that were found, what was tested, and what platform was used.
Vulnerabilities may either be basic or pretty crucial. For example, below is a screenshot from scanning the
nginx:latest image in Docker Hub.
docker scan found a SQL injection attack, which is one of the most common web attacks.
In a highly secure production-level environment, you want to confirm that the developer tools you’re using are up to par with your expectations. In hindsight, container images are a tool that you use to deploy applications. A lot of container images, because there’s a base image, are built by people that aren’t you. Because of that, it’s a great practice to confirm what the container image is and if it’s secure.