How to Secure Docker Images: Run as Non‑Root, Use Private Registries, and Minimize Attack Surface

Is Your Image Secure?

Compared with traditional servers and virtual machines, Docker containers provide a more secure environment by isolating application components, reducing the attack surface, and limiting the impact of a breach.

Nevertheless, understanding Docker's inherent security risks is essential for protecting containerized systems.

Many security measures mirror those for servers, such as monitoring container activity, limiting resource consumption, following good application design practices, patching vulnerabilities, and safeguarding credentials.

However, Docker also requires specific security steps, which are outlined below.

Run Container Images as a Non‑Root User

By default, Docker grants root privileges to processes inside a container, giving them full control over the container and host. Just as you avoid running processes as root on a Linux server, you should avoid running containers as root.

Neglecting this default can lead to insecure images that grant root access, allowing attackers to steal API keys, tokens, passwords, or compromise the host system.

Developers may unintentionally create images with administrative access via Dockerfile commands, which could erase data or alter host settings.

How to Prevent Containers from Running as Root

If the base image's user is unknown, enforce a custom non‑root user or group so the container process only accesses required resources.

Set a non‑root user in the Dockerfile.

First, create a dedicated user or group with only the permissions needed by the application.

Then add a USER instruction in the Dockerfile and build/run the image using that user.

FROM centos:7

RUN groupadd -g 1000 basicuser && \
    useradd -r -u 1000 -g basicuser basicuser

USER basicuser

Specify a non‑root user with the --user flag in docker run.

The --user option overrides any user set in the Dockerfile, ensuring the container runs with the lowest privileges (e.g., UID 1009). However, this does not fix inherent image vulnerabilities, so defining a non‑root user in the Dockerfile is recommended.

$ docker run --user 1009 centos:7

Use a Private Registry

A private registry is an isolated image repository hosted by your organization, either on‑premises or via cloud services such as Amazon ECR, Azure Container Registry, Google Container Registry, Red Hat Quay, or JFrog Artifactory.

Private registries offer advanced features that improve image security, including:

Comprehensive image scanning for threats and unpatched vulnerabilities.

Strict governance with role‑based access control (RBAC) and compliance monitoring.

Digital signatures, image authentication, and anti‑tampering mechanisms.

Support for multi‑environment repositories for development, testing, and production.

Public registries like Docker Hub typically provide only basic services, requiring you to trust the image publisher, which may not follow the same security standards.

Consequently, you might pull images containing malicious or outdated code, exposing your containers to data leaks.

Keep Images Minimal

Larger images increase the attack surface. While you cannot eliminate the base Linux OS, you can choose minimal base images and include only the components you need.

Choose the Smallest Base Image

Some Docker Hub images are significantly larger than others; for example, certain Ubuntu variants are twice the size of minimal alternatives.

When pulling an image, prefer the smallest variant and then add only the required packages and dependencies.

Docker Hub displays the compressed size of each image, as shown in the example of a minimal Ubuntu image.

After pulling, you can inspect the actual size with docker images.

$ docker images

Locate the entry for the recently downloaded image.

Optimize Dockerfile and .dockerignore

Create a Dockerfile that builds a streamlined image, consisting of a base layer and your own layers. Exclude unnecessary build artifacts by adding a .dockerignore file in the build context.

Multi‑Stage Builds

Another way to reduce image size is to use Docker multi‑stage builds (available in Docker 17.05+). Multiple FROM statements allow you to copy only the needed artifacts to the final stage.

Example:

FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]

Verify Image Integrity

Improving container security also involves verifying images before pulling them. Docker Engine 1.8 introduced Docker Content Trust, which enables digital signing and verification of images.

When enabled, Docker automatically checks the signature of images pulled from remote registries, confirming the publisher's identity.

Activate Docker Content Trust by setting the environment variable:

export DOCKER_CONTENT_TRUST=1

This setting applies to the current shell; to enable it system‑wide, configure the variable in a shared environment file.

While Docker Content Trust does not assess image quality, it helps prevent tampering and unauthorized access during transfer, keeping your images clean.

Article originally from JFrog DevOps