How to idiomatically access sensitive data when building a Docker image?

Sometimes there is a need to use sensitive data when building a Docker image. For example, an API token or SSH key to download a remote file or to install dependencies from a private repository. It may be desirable to distribute the resulting image and leave out the sensitive credentials that were used to build it. How can this be done?

I have seen docker-squash which can squash multiple layers in to one, removing any deleted files from the final image. But is there a more idiomatic approach?

  • babel-watch doesn't work from docker container on windows host when mounting a host directory as a network share
  • How to run etcd cluster in docker using ansible?
  • Optimising cargo build times in docker
  • Dockerizing any Angular SPA app that runs in node
  • Building an web app which can perform npm tasks
  • How do you add a volume to a container in the IBM Bluemix Docker cloud?
  • How to dynamically modify the startup parameters of a running container?
  • How can I run specific android app automatically by using Docker?
  • Running multiple time the same docker image
  • Share container definition in multiple docker compose
  • $ bundle install --path /cache Could not locate Gemfile
  • Docker exposed port unreachable
  • 3 Solutions collect form web for “How to idiomatically access sensitive data when building a Docker image?”

    Regarding idiomatic approach, I’m not sure, although docker is still quite young to have too many idioms about.

    We have had this same issue at our company, however. We have come to the following conclusions, although these are our best efforts rather than established docker best practices.

    1) If you need the values at build time: Supply a properties file in the build context with the values that can be read at build, then the properties file can be deleted after build. This isn’t as portable but will do the job.

    2) If you need the values at run time: Pass values as environment variables. They will be visible to someone who has access to ps on the box, but this can be restricted via SELinux or other methods (honestly, I don’t know this process, I’m a developer and the operations teams will deal with that part).

    The way we solve this issue is that we have a tool written on top of docker build. Once you initiate a build using the tool, it will download a dockerfile and alters it. It changes all instructions which require “the secret” to something like:

    RUN printf "secret: asd123poi54mnb" > /somewhere && tool-which-uses-the-secret run && rm /somewhere
    

    However, this leaves the secret data available to anyone with access to the image unless the layer itself is removed with a tool like docker-squash. The command used to generate each intermediate layer can be found using the history command

    Matthew Close talks about this in this block article.

    Summarized: You should use docker-compose to mount sensitive information into the container.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.