Secure Container Image

While Creating a new container image is fairly easy and straightforward for development purposes, you should consider building a secure container image for production use. Below are some basic considerations.

No Source Code

It's a common mistake to copy too much data/information into a container image. In general, you should only have the content that's absolutely necessary to run your application. But there are things that often make it into a container image that you may not realize:

  • Source code, build files are easily copied into a runtime container image by accident when using a Dockerfile.

  • Version control directories, such as .git are easily copied into a runtime container image by accident when using a Dockerfile.

Jib automatically builds thin container images without the source.

No Secrets/Credentials

Do not copy secrets and/or credentials into a container image (e.g., do not copy a service account key file!). For the most part, secrets can be stored in the runtime environment (e.g., a Kubernetes Secret), or better, a secret store (e.g., Cloud Secret Manager, or HashiCorp Vault).

Minimal Base Image

Many base images comes with all the command line utilities from a typical Linux distribution (e.g., a shell, package manager, etc). These container images may allow you (or an attacker!) to get into a shell, and install additional tools. To reduce the attack surface, consider using a minimal base image that has the least attack surface. These images will be more secure, but may also be harder to debug.

Jib uses the Distroless base image by default.

Non-Root User

One of the most overlooked configuration for a container image is which user is used to run your application? In a VM environment, you would never want to run an application as root. It's no different in a container. Every container image may have a different set of non-privileged users.

For example, for a Distroless base image (using a debug image that has a shell):

docker run -ti --rm --entrypoint=sh \
  gcr.io/distroless/java:debug -c "cat /etc/passwd"

You'll see that it has only 3 users:

root:x:0:0:root:/root:/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/sbin/nologin
nonroot:x:65532:65532:nonroot:/home/nonroot:/sbin/nologin

But, an AdoptOpenJDK base image has more system users, and you'll need to pick the one you want to use as the user to run your application:

docker run -ti --rm adoptopenjdk:11-jre-hotspot-bionic cat /etc/passwd

Jib uses root user by default. You should configure it to use a non-root user according to the base image you use. For example:

PROJECT_ID=$(gcloud config get-value project)
./mvnw compile com.google.cloud.tools:jib-maven-plugin:2.4.0:build \
  -Djib.container.user=nonroot:nonroot
  -Dimage=gcr.io/${PROJECT_ID}/helloworld

Validate that the JVM was started with the nonroot user:

PROJECT_ID=$(gcloud config get-value project)

docker pull gcr.io/${PROJECT_ID}/helloworld
docker run -ti --rm --entrypoint=java \
  gcr.io/${PROJECT_ID}/helloworld \
  -XshowSettings:properties -version

Look for the user.name property is now nonroot.

Summary

So, what do the automated tools do by default?

PreviousContainer ImageNextContainer Awareness

Last updated