Feature request: add docker secret file support for AWS secrets

[e3elettronica]

We are using latest docker container image.
It would be safe and usefull to be able to provide AWS key ID and secret using standard docker secrets way.

The same is already implemented for database user password, which could be provided either by DB_PASS env variable, or by DB_PASS_FILE secret file env variable, or inside the config file.

It could be implemented either in the entrypoint with some code like the following

if [ -n "${AWS_ACCESS_KEY_ID_FILE-}" ]; then
  if [ -f "${AWS_ACCESS_KEY_ID_FILE}" ]; then
    export AWS_ACCESS_KEY_ID=$(cat "${AWS_ACCESS_KEY_ID_FILE}")
  fi
fi

if [ -n "${AWS_SECRET_ACCESS_KEY_FILE-}" ]; then
  if [ -f "${AWS_SECRET_ACCESS_KEY_FILE}" ]; then
    export AWS_SECRET_ACCESS_KEY=$(cat "${AWS_SECRET_ACCESS_KEY_FILE}")
  fi
fi

or inside the program itself.

At the moment it is needed to create a custom image wrapping the default entrypoint in a custom one, performing the secrets checking/reading/export before running the original entrypoint.

[deitch]

Hi and welcome.

I am somewhat confused. Why are you able to do it with DB_PASS but not AWS_*? If you can run docker run -e DB_PASS=*** then why not -e AWS_SECRET_ACCESS_KEY=***?

Or possible docker run --env-file as an option?

[e3elettronica]

The point of the feature request is to provide all the secrets to the docker container in a safe way.

Providing secrets through command args, on in docker compose environment variables, or in docker compose environment files is not safe.
Command args can be read with either in history, or using ps command (ps -elf) or by inspecting the container configuration (docker inspect container-name).
Environment variables provided in docker compose or through docker compose environment files can be read by inspecting the container configuration too.

The current common and best way to provide sensitive data to docker container is the use of docker secrets
https://docs.docker.com/engine/swarm/secrets/
https://docs.docker.com/compose/how-tos/use-secrets/

However this way needs that the container is able to accept extra environment variables (usually ending with _FILE), read the secret files these extra variables point to and then assign the content of these secret files to the destination variables inside the container.
This must be done during the container bootstrap phase.
This is the way the mysql official container image does.

With the current version of mysql-backup you can do this using DB_PASS_FILE.
However you cannot do this using AWS_ACCESS_KEY_ID_FILE and AWS_SECRET_ACCESS_KEY_FILE, which are very sensitive info too.

[deitch]

compose and swarm both follow the philosophy of, "we will mount this file in the container and then you can do what you want with it." This:

services:
  myapp:
    image: myapp:latest
    secrets:
      - my_secret
secrets:
  my_secret:
    file: ./my_secret.txt

Is just a convenient way of doing:

docker run -v ./my_secret.txt:/run/secrets/my_secret:ro myapp:latest

The code would then need to know how to read that file, hence the request for AWS_ACCESS_KEY_ID_FILE.

The simpler approach is:

docker run -it --rm --env-file my_secrets image

and fill the env-file up with your secrets. But you are right, that will show up in the container inspect:

"Env": [
                "FOO=bar",
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],

(OK, FOO=bar is not very secret, but it gets the idea across)

So you are looking to have an equivalent to what it does with compose, to have mysql-backup read (some of) its environment vars (the secret ones, at least) from file(s), rather than env vars. Is that it?

Is it worth the effort? mysql-backup already supports a yaml config file, which you can mount in (using docker run, compose, etc.). That is the way most installs (and all complex ones) are done, and therefore the confidential info never ends up in the environment or the docker inspect. What is the benefit of adding another way?