You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 13, 2019. It is now read-only.
Right now unless I am missing something, there is no easy or safe way to provide an ssh key to the docker build so that dependencies that are pulled with ssh would be resolved properly.
The idea is to open a web server on the docker network to expose the ssh key or any other secrets that the Dockerfile could fetch and once used, delete it, all in one transaction, leaving no trace behind whatsoever.
RUN wget -O ~/.ssh/id_rsa http://192.168.99.1:8080/secrets/file/id_rsa && mix do deps.get, deps.compile && rm ~/.ssh/id_rsa
We should also add github as an known host automatically:
# Adding github to known hosts
RUN mkdir ~/.ssh && ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts
TBH I think this is out of scope of this project. I can't even imagine how it could be implemented in a generic way. Sooner or later you will want to use a custom Dockerfiles where you can do whatever you need :)
I should be fairly simple. We could expose in a configurable way any file over http like Habitus is doing. Starting a webserver using Plug when the mix task build is launched should not be so hard.
RUN wget -O ~/.ssh/id_rsa http://192.168.99.1:8080/identity && mix do deps.get, deps.compile && rm ~/.ssh/id_rsa
It's impossible to address this issue with a custom Dockerfile alone, you need to be able to serve over http what you want to share if you want to make sure you do it in a clean way.
I agree that people will most probably want to customize their Dockerfile. What i am proposing is to let them expose files they have locally over http so that it can be consumed by docker build.
And maybe we dont do something generic but only addressing the core issue of passing your ssh key.
Right now unless I am missing something, there is no easy or safe way to provide an ssh key to the docker build so that dependencies that are pulled with ssh would be resolved properly.
Reading on http://blog.cloud66.com/using-ssh-private-keys-securely-in-docker-build and how Habitus is solving this elegantly, I believe their solution is best and should be relatively simple to implement.
The idea is to open a web server on the docker network to expose the ssh key or any other secrets that the Dockerfile could fetch and once used, delete it, all in one transaction, leaving no trace behind whatsoever.
We should also add github as an known host automatically:
What do you think @teamon ?
The text was updated successfully, but these errors were encountered: