CODEWITHSUNDEEP
dockerdockerfile
jmanuelrosa
jmanuelrosa

Reputation: 336

Reuse user in multi-stage Dockerfile

As you know, for security reasons, isn't good to use root user execept if you need it. I have this Dockerfile that I use with multi-stage steps

FROM golang:latest AS base

WORKDIR /usr/src/app

# Create User and working dir
RUN addgroup --gid 42000 app
RUN useradd --create-home --uid 42000 --gid app app
RUN chown -R app:app /usr/src/app
RUN chmod 755 /usr/src/app

# Compile stage based on Debian
FROM base AS builder

USER app

# Copy form computer to current WORKDIR container
COPY . .

# Exit immediately if a command exits with a non-zero status
RUN set -xue && \
  make go-build-linux

# Final stage
FROM debian:latest

USER app

EXPOSE 14001

RUN apt-get update && \
  apt-get install -y ca-certificates

WORKDIR /usr/src/app

COPY --from=builder /usr/src/app/server .

CMD ["./server"]

The problem is that I'm trying to reuse the user in all steps but seems to be that the user scope is by stage and I don't know how to reuse it.

Do you know how I can reuse a user in a multi-stage Dockerfile and try to avoid to use root user from Dockerfile?

Thanks!

Upvotes: 5

Views: 5917

Answers (1)

masseyb
masseyb

Reputation: 4132

TL;DR;

It is not possible to re-use the same user in multiple stages of the docker build without re-creating the user (same UID and GID at least) in each stage as each FROM is starting from a clean slate FROM image in which a user UID=42000 and GID=42000 is unlikely to already exist.

I am not aware of any recommendation against building as the root user inside a container. It is recommended to run services as unprivileged users however certain containers processes must be run as the root user (i.e. sshd):

The best way to prevent privilege-escalation attacks from within a container is to configure your container’s applications to run as unprivileged users. For containers whose processes must run as the root user within the container, you can re-map this user to a less-privileged user on the Docker host. The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.

Tip: The Haskell Dockerfile Linter will complain if the last user is root which you can configure as a git pre-commit hook to catch things like that before committing teh codez.

Upvotes: 7

Related Questions