a simple way to provide sensitive and/or dynamic env for docker-compose

[bayeslearnerold]

I understand this is a simple tool not meant for production, but it would be nice if there is a simple elegant way to accomplish this, as having plain passwords lying around makes many people nervous these days.

As an example, maybe each service can have a separate, optional .env.sh file with contents like:

MYUID=$(id -u)
yyy_password=$(pass docker-compose/services/mssql)

a wrapper is then used to inject the dynamic env before invoking the real docker-compose? This probably means that a gpg passphrase will be needed once for server.sh xxx operation every so often?

# docker-compose-wrapper file
##########
function compose_wrapper() {
    if [ -f "../../.usewrapper" ]; then 
      set -a
      [-f ".env.sh"] && source <(cat .env.sh )
      set +a
    fi
    $real_compose  "$@"
}
...

compose_wrapper "$@"
##############

[borjapazr]

Hi @bayeslearner ,

I can think of several ways to provide a solution to the problem of dynamic environment variables or runtime. One of them would be using the method you describe. Another would be generating the .env file before executing the docker-compose command, taking advantage that our entry point is the Makefile would not be complicated. And, the last one, using a wrapper similar to the one that you comment and described in the following gist https://gist.github.com/mikeclarke/7620336.

About trying to hide the passwords and not show them in plain text, that should not be a problem. Why? Because this is running on a server, which should be secured and accessible only by the server administrator. Even if we avoid having passwords in plain text, this would not be a sufficient mechanism to ensure that, even if someone compromised our server, they would not obtain confidential information. Being able to access the .env.sh file would already be a way to obtain passwords or sensitive details.

Anyway, the possibility of adding dynamic information seems to me a good idea. If you feel like contributing, go ahead, as any contribution will be welcome 🚀

Thanks @bayeslearner !

[bayeslearnerold]

so I settled on making just one change in your common.mk:

ifeq ($(wildcard $(ROOT_DIR)/docker-compose.sh),)
    DOCKER_COMPOSE := docker-compose
else
    DOCKER_COMPOSE := bash docker-compose.sh  
endif

For each individual service, they are free to implement a wrapper however it sees fit.

For example, I have a mssql service, there I added 2 files one is docker-compose.sh, the other .env.dynamic.

#!/bin/bash
set -a
[ -f ".env.dynamic" ] && source <(cat .env.dynamic | sed -e '/^#/d;/^\s*$/d')
set +a
docker-compose "$@"

The password is saved in a gpg encrypted store, without the passphrase to the secret-store, having access to .env.dynamic is still useless.

#An encrypted password test
MSSQL_ROOT_PASSWORD=$(pass docker-compose/services/mssql)

I'm not sure I understand how exec could be used. According to docker-compose documentation, I have to use the environment variables of the shell to influence how it works, and not merely variables of the parent process. So I have to export those variables into the shell, no matter what. Am I missing something?