What is a Docker image?

If cloud-native applications are the buildings that define modern IT landscapes, Docker images are the bricks used to construct those buildings. Understanding the fundamentals of Docker images is essential for developers working with containerization applications.

To provide guidance on working with Docker images, this article explains what Docker images are, which roles they play in modern CI/CD pipelines, and how to build and secure Docker images.

Definition of a Docker image

A Docker image is a read-only snapshot of the contents necessary to run a container. Put another way, a Docker image represents the blueprint for deploying and running a containerized application. 

To run a container, developers must write their application code, understand the dependencies their application requires, and then download or create a docker image which supports these requirements. Additionally, developers must download any requisite dependencies or special commands needed to set up the container environment. Lastly, use a container runtime (such as runC or containerd) to launch live containers based on the Docker image.

Docker images vs. container images

Technically speaking, the term Docker image refers to container images that are built using tooling from Docker, which is one of several container management platforms available today. However, the term often appears generically to refer to any type of container image, even in contexts where no Docker tools are used.

This is because Docker was the first container platform to go mainstream, so Docker image became a shorthand for container images in general. So, when you hear Docker image, don’t assume it refers to an image that was built with, or can only run on, the Docker platform. Typically, Docker images can operate on any platform or within any environment (including Kubernetes, another popular container engine) that supports standards-compliant container images.

What’s inside Docker images?

Docker images (and any other type of container image) typically include the following components:

• Application code: This code implements the functionality specific to the application developers want to run. Note that application code is typically synonymous with first-party code, meaning that a company’s developers write this code themselves. 

• Dependencies: Dependencies include libraries, frameworks, third-party applications, and any other components that must be present for an application to run.

• Commands: Often, container images include commands that run automatically on startup. The commands perform steps such as installing additional software using a package management system, or opening specific network ports.

• File system: Image definitions include a file system, which stores the files that need to be present when the container runs. Importantly, file systems inside containers are non-persistent, meaning that data within them will disappear permanently when the container shuts down.

These various contents are organized into a series of layers. Usually, developers create Docker images by starting with a base layer that they obtain from an external source, such as an image that represents a Linux distribution. Then, they add layers containing the application code and other contents that need to be present within the image.

Building Docker images

The simplest way to build a Docker image is to start with a Dockerfile. A Dockerfile is a text file that describes the contents of an image. For example, here’s a simple Dockerfile for a basic Python app:

# Use an official Python runtime as the base image
FROM python:3.10-slim

# Set the working directory in the container
WORKDIR /app

# Copy the requirements file to the container
COPY requirements.txt .

# Install the dependencies
RUN pip install --no-cache-dir -r requirements.txt

# Copy the rest of the application code to the container
COPY . .

# Expose the port the app runs on
EXPOSE 5000

# Command to run the application
CMD ["python", "app.py"]

To build an image based on this Dockerfile, first use the cd command to navigate to the directory where you saved the Dockerfile. Then, run the docker build command:

docker build -t myapp:1.0

This tells Docker to create an image named myapp and assign it the tag 1.0. Note the trailing “.” at the end of the command; this is important because it tells Docker to create the image based on the Dockerfile in the present working directory.

How to run containers using Docker images

After building an image, you can run containers based on it using a command such as:

docker run myapp:1.0

Alternatively, you could create a Kubernetes Deployment that references the image and use it to launch containers in Kubernetes based on the image. For example, the following YAML code defines a simple Deployment based on the image myapp:1.0:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
	app: myapp
spec:
  replicas: 3  # Number of desired pods
  selector:
	matchLabels:
  	app: myapp
  template:
	metadata:
  	labels:
    	app: myapp
	spec:
  	containers:
  	- name: myapp-container
    	image: myapp:1.0  # The image to use for the container
    	ports:
    	- containerPort: 8080  # Port the container exposes

To run containers in Kubernetes based on this Deployment, you’d save the YAML code as a file, then apply it with:

kubectl apply -f /path/to/deployment.yaml

Docker image security risks

Because the contents of a Docker image determine what components are present inside a live container, security risks within Docker images are a common source of container security risks. Common container image security issues include:

• Risks recorded through the Common Vulnerability and Exposure (CVE) system, which publicly registers known security vulnerabilities in a National Vulnerability Database (NVD).

• Third-party open source code that was not vetted by an organization’s own developers.

• Package managers or shells that could become attack vectors for bad actors.

• Commands that create insecure configurations, such as exposing an insecure network port or granting elevated privileges.

If these flaws go undetected, they can create security risks within production environments that include containers based on the insecure images, ultimately causing breaches.

Best practices for securing Docker images

To mitigate Docker image security risks, consider best practices like the following:

• Avoid untrusted container images: Source container images from trustworthy sources, such as open source projects hosted on Github or Dockerhub.

• Scan images: While container scanners can’t detect every potential risk, they are effective in identifying known vulnerabilities.

• Use minimal, hardened images: The less code you include inside container images, the smaller your potential attack surface.

• Sign images: Container image signing creates a digital identifier that you can use to verify the provenance of an image. Signing helps mitigate the risk that threat actors will plant a malicious image in place of a legitimate one.

Protecting Docker images with Chainguard

The steps we just described can help to reduce common container image security risks. But to truly build better software from a secure foundation, developers can choose Docker images from Chainguard. By rebuilding container images from source, including only the components required to build and run your applications, and offering a CVE remediation SLA, Chainguard manages your container images so you don’t have to.

Learn more about the role of Chainguard images in container security by reading our analysis of the hardened container landscape.