Add _FILE environment variable variants to read sensitive configuration from files

[Radiergummi]

We're running Vouch in our Swarm cluster. All applications are configured from the CI deployment pipeline, and Vouch is no exception here. Currently, the JWT secret and OAuth provider configuration have to be passed as environment variables, which provides no protection for the values, so they are visible from internal monitoring dashboards which are accessible to all developers. We would like to restrict access to sensitive data like the OAuth client credentials however.

This is easily possible by using Docker Secrets, which essentially mount secret values as files below /run/secret/. Lots of applications include support for ACME_SECRET and ACME_SECRET_FILE to allow passing the path of a file instead of the secret value itself.

It would be great if Vouch supported _FILE variants of sensitive configuration settings, or maybe just all of them!

In the mean time, there's a workaround: Dynamically generating a configuration file and providing that as a secret:

services:
  vouch:
    environment:
      VOUCH_CONFIG: /config/dynamic_config.yaml
      # place other configuration here
    secrets:
      - source: vouch_config
        target: /config

secrets:
  vouch_config:
    file: ./dynamic_config.yaml

The configuration itself could be written using something like this in a build script:

echo jwt.secret=$JWT_SECRET >> ./dynamic_config.yaml
echo oauth.client_secret=$OAUTH_CLIENT_SECRET >> ./dynamic_config.yaml

[bnfinet]

@Radiergummi that seems like a pretty easy workaround and nice solution that covers any and all secrets held in the config both today and tomorrow.

I think using a template or sed to build the config and then setting VOUCH_CONFIG is a fine approach.

As per https://docs.docker.com/engine/swarm/secrets/ ...
"You can store any file as a secret as long as it is smaller than 500 KB"

Most VP configs come in at less that 5KB (or even less that 2KB) so there's plenty of room to work with there.

If we linked to this issue from the README would that suffice to document this mechanism?

[Radiergummi]

@bnfinet Yep, sure. It works fine this way :)