Use Docker environment variables for credentials

Recently we are trying to find a proper way of injecting credentials via environment variables to the spring based application we run in the container.

The exact process includes

  • How can I run multiple statements using json array format for Docker ENTRYPOINT?
  • Docker reuse port in a consul TCP health check cycle
  • Set up swarm mode Docker Swarm using Vagrant
  • “Could not delete ./” when I use composer in docker
  • How do I make a Python Docker image an OpenWhisk action?
  • Linking exposed port of docker with with the default nginx port
    • A bootstrap shell script, which docker CMD runs as an entry point
    • Export bunch of credentials inside the script
    • Run the application at the end of the script file

    With this way, none of docker inspect, docker exec [container_id] envor bash into docker container and run env will see these environment variables, ie. what we injected with bootstrap script are opaque.

    So the question: is there anything else we should consider with this solution? any obvious glitches?

    We are pretty new to docker world, so this behaviour, about making environment variables injected by shell script are not visible since after, is there any document explaining why? we haven’t found a good doc but just found it’s working in this way

    PS. will docker change this behaviour in future?

    Thanks in advance!

  • Docker isn't caching my RUN commands correctly
  • Small binary file is changed on building Docker image using spotify maven plugin
  • ERROR: mkdir with chown not working in Dockerfile (nginx with php-fpm)
  • GitlabCI free shared runners to provision Ubuntu instead of CoreOS?
  • Docker run appears to ignore the name argument
  • Adding a new NIC to a Docker container in a specific order
  • 2 Solutions collect form web for “Use Docker environment variables for credentials”

    That looks like a very good approach overall.

    However, I don’t think you can complete hide the environment variables from someone who has permissions to inspect process envs. It seems to me that if you find out the process id of the application process (inside the container or from the host) you should be able to find its environment in /proc. Won’t show up as docker env, but it’s still in there somewhere.
    Also, any such person can probably connect to your Vault directly anyway.

    Meaning, yes, this will reliably not make the environment of child processes show up in the container environment, but it does not really hide it from anyone (who can already access your host machine and control docker).

    Still, congrats on this setup. Much better than having credentials built into images.

    Interesting find. I think that is because the environment variables are local to the shell session where your app is running. See

    Process locality

    The values of environment variables are local, which means they are
    specific to the running process in or for which they were set. This
    means that if we open two terminal windows (which means we have two
    separate bash processes running), and change a value of an environment
    variable in one of the windows, that change will not be seen by the
    shell in the other window or any other program currently on the

    Regarding risk, there is a good discussion here For example, you might have debug apps in the same session that prints out or logs the environment, any child processes also see the environment variable.

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