The title speak for itself. I have to create a dockerfile for my company and it must clone the private repo where all the server files are. Since i can’t order to clone the repo in the dockerfile cause i have to enter credentials i discover that you can build an image directly with a github repo url. But i don’t want to put (not immediately) and i’d like to do it with a local dockerfile. Is this possible ?
What we do is inject via environment variables any sensitive material. Since we have CI for our Docker images, those secrets are stored safely in the CI environment.
The build pipeline then passes those variables to Docker using args. Inside the build, those secret are either materialized into a file (echo $secret > file) that we later remove or piped into the command if it supports it (echo $secret | someCommand.sh)
That also allows developers to use their own credentials when they build the image on their workstation. They also use build args and specify their creds.
The build pipeline then passes those variables to Docker using args
Is that secure though @aleveille? From the Dockerfile reference that you linked to:
Warning: It is not recommended to use build-time variables for passing secrets like github keys, user credentials etc. Build-time variable values are visible to any user of the image with the docker history command.
No it’s not. The process I describe are for “shared” secret, if such a thing exists. What we can inject in such way is typically read-only user credentials or something similar. This allows the image to pull artifacts from our private repository.
Since all our developers have read+write access to the repo, having a read-only user in the docker file is of minimum risk in our case. Injecting the password at build-time also allows for easy password rotation every now and then, so that if someone left the company, he can’t use those shared credentials forever.
For more “secret” secret, we are doing something else (which has its flaws) so we’re looking into secrets vault.
You don’t want to let the SSH key leave traces in the resulting image. If you ADD it during the build, or write a file with RUN echo […] , it will linger in one of the layers, even if you do a RUN rm afterwards.
There are two ways to use a secret SSH key during the build and still get a clean image afterwards:
Squashing (running build with the --squash flag) to create a single diff between the first and last layer, leaving out intermediate states.
Using multi-stage builds. You can add a private deploy key into an intermediate image, clone everything you need, and only pass the cloned repo directories to the final image.
I wrote about how we solved it at Connected Cars, where we inject a github token with the docker --build-arg to avoid it being committed to the container.