Back

Docker “FROM scratch” for Rust Applications - Building Tiny and Secure Container Images

14 Nov, 2022

One of the benefits of using Rust is the possibility of building fully statically linked binaries. Those binaries can run in a Docker container that is created from an empty image instead of a Linux distribution. These images are built “FROM scratch”. scratch is also used as a starting point to base images for Debian and busboy.

With a “FROM scratch”-image, your executable runs in an empty container, which includes nothing but the absolute minimum for the program to work. One benefit is the image's tiny size. Another is that it isolates the execution environment of a process. Even if an attacker successfully hacks your software, they find themselves in an empty container with no further exploitable software.

In our example Dockerfile below, we’re building a Rust binary with SQLite, OpenSSL, and PostgreSQL as additional dependencies. They all have to be linked statically to work in a “FROM scratch”-image.

1FROM docker.io/library/rust:1.62-alpine as builder
2RUN apk add --no-cache musl-dev sqlite-static openssl-dev openssl-libs-static pkgconf git libpq-dev
3
4# Set `SYSROOT` to a dummy path (default is /usr) because pkg-config-rs *always*
5# links those located in that path dynamically but we want static linking, c.f.
6# https://github.com/rust-lang/pkg-config-rs/blob/54325785816695df031cef3b26b6a9a203bbc01b/src/lib.rs#L613
7ENV SYSROOT=/dummy
8
9# The env vars tell libsqlite3-sys to statically link libsqlite3.
10ENV SQLITE3_STATIC=1 SQLITE3_LIB_DIR=/usr/lib/
11
12# The env var tells pkg-config-rs to statically link libpq.
13ENV LIBPQ_STATIC=1
14
15WORKDIR /wd
16COPY . /wd
17RUN cargo build --bins --release
18
19FROM scratch
20ARG version=unknown
21ARG release=unreleased
22LABEL name="Product Name" \
23      maintainer="info@company.com" \
24      vendor="Company AG" \
25      version=${version} \
26      release=${release} \
27      summary="High-level summary" \
28      description="A bit more details about this specific container"
29
30COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
31COPY --from=builder /wd/target/release/binaryName /
32CMD ["./binaryName"]

Build the image using Podman:

1podman build --file Dockerfile --tag image:tag --build-arg version=1.1 --build-arg release=1

Build the image using Docker:

1docker build --tag image:tag --build-arg version=1.1 --build-arg release=1 .

And lastly, build this image automatically with your GitLab-Runner CI on every push to master, every new git tag, and the option to trigger the build on a merge request in GitLab’s UI:

1stages:
2  - docker
3
4build-docker-scratch:
5  variables:
6    GIT_DEPTH: 500
7  stage: docker
8  image:
9    name: alpine:3.16.2
10  script:
11    - apk add podman
12    - DOCKER_TAG_NAME="${CI_COMMIT_TAG:-master}"
13    - podman build --file $CI_PROJECT_DIR/Dockerfile --tag $CI_REGISTRY_IMAGE:$DOCKER_TAG_NAME --build-arg version=$DOCKER_TAG_NAME --build-arg release=$DOCKER_TAG_NAME --target void
14    - podman login --tls-verify --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
15    - podman push --tls-verify $CI_REGISTRY_IMAGE:$DOCKER_TAG_NAME
16  rules:
17    - if: '$CI_COMMIT_REF_NAME == "master"'
18    - if: '$CI_COMMIT_TAG != null'
19    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
20      when: manual
21      allow_failure: true

This allows us to build tiny, secure container images for our software. The images are immediately available on our registry to deploy and use in other steps of the CI/CD. If you have any feedback or questions, don't hesitate to get in touch with us.

Written by:

Lucas Betschart

CEO

Email | LinkedIn

Back