Path interpretation in a Dockerfile

Question

I want to run a container, by mounting on the fly my ~/.ssh path (so as to be able to clone some private gitlab repositories).

The

COPY ~/.ssh/ /root/.ssh/

directive did not work out, because the Dockerfile interpreted paths relative to a tmp dir it creates for the builds, e.g.

/var/lib/docker/tmp/docker-builder435303036/

So my next shot was to try and take advantage of the ARGS directive as follows:

ARG CURRENTUSER

COPY /home/$CURRENTUSER/.ssh/ /root/.ssh/

and run the build as:

docker build --build-arg CURRENTUSER=pkaramol <whatever follows ...>

However, I am still faced with the same issue:

COPY failed: stat /var/lib/docker/tmp/docker-builder435303036/home/pkaramol/.ssh: no such file or directory

1: How to make Dockerfile access a specific path inside my host?

2: Is there a better pattern for accessing private git repos from within ephemeral running containers, than copying my .ssh dir? (I just need it for the build process)

Answer 1

Docker Build Context

A build for a Dockerfile can't access specific paths outside the "build context" directory. This is the last argument to docker build, normally .. The docker build command tars up the build context and sends it to the Docker daemon to build the image from. Only files that are within the build context can be referenced in the build. To include a users .ssh directory, you would need to either base the build in the .ssh directory, or a parent directory like /home/$USER.

Build Secrets

COPYing or ADDing credentials in at build time is a bad idea as the credentials will be saved in the image build for anyone who has access to the image to see. There are a couple of caveats here. If you flatten the image layers after removal of the sensitive files in build, or create a multi stage build (17.05+) that only copies non sensitive artefacts into the final image.

Using ENV or ARG is also bad as the secrets will end up in the image history.

There is a long an involved github issue about secrets that covers most the variations on the idea. It's long but worth reading through the comments in there.

The two main solutions are to obtain secrets via the network or a volume.

Volumes are not available in standard builds, so that makes them tricky.

Docker has added secrets functionality but this only available at container run time for swarm based containers.

Network Secrets

Custom

The secrets github issue has a neat little net cat example.

nc -lp 10.8.8.8 8080 < $HOME/.ssh/id_rsa &

And using curl to collect it in the Dockerfile, use it, and remove it in the one RUN step.

RUN set -uex; \
    curl -s http://10.8.8.8:8000 > /root/.ssh/id_rsa; \
    ssh -i /root/.ssh/id_rsa root@wherever priv-command; \
    rm /root/.ssh/id_rsa;

To make unsecured network services accessible, you might want to add an alias IP address to your loopback interface so your build container or local services can access it, but no one external can.

HTTP

Simply running a web server with your keys mounted could suffice.

docker run -d \
  -p 10.8.8.8:80:80 \
  -v /home/me/.ssh:/usr/share/nginx/html:ro \
  nginx 

You may want to add TLS or authentication depending on your setup and security requirements.

Hashicorp Vault

Vault is a tool built specifically for managing secrets. It goes beyond the requirements for a Docker build It's written and Go and also distributed as a container.

Build Volumes

Rocker

Rocker is a custom Docker image builder that extends Dockerfiles to support some new functionality. The MOUNT command they added allows you to mount a volume at build time.

Packer

The Packer Docker Builder also allows you to mount arbitrary volumes at build time.