Load Vault token from file

[orinokai]

Vaultenv is a fantastic tool and has really helped my organisation simplify our developer workflow. One additional feature that I’d love is the ability to load the Vault token from a file.

We currently use Docker and distribute the token to our swarm nodes via the VAULT_TOKEN environment variable. The problem is that if an unauthorised user gained access to a node they could simple do docker inspect to retrieve the token.

If Vaultenv could load the token from a file, e.g. via a path specified with the VAULTENV_TOKEN_FILE environment variable, we could then use Docker Secrets to distribute the token to the node, which would be more secure.

[duijf]

Glad you're enjoying vaultenv!

We currently do support loading config from files in the dotenv format, as documented here: https://github.com/channable/vaultenv#behavior-configuration

Does that suit your needs? Or would you need more flexibility? E.g. like being able to specify where to search for these files or something else

[orinokai]

Ah, of course. I hadn't considered that I could specify the token in the config file. I can then specify a custom path for my docker secret containing the env file. Thanks - problem solved!

[orinokai]

Actually, having just tried this it does work but makes the docker-compose file a little messy. So, yes please, to keep things consistent it would be great to be able to specify VAULTENV_CONFIG_FILE as an environment variable, similar to VAULTENV_SECRETS_FILE.

[duijf]

Could you post a minimal example of the docker compose file so we can get a feel for the problem?

[orinokai]

Yes certainly, thanks. I'm putting my VAULT_TOKEN in a config file and passing it as a Docker secret. Currently I have to specify a target so that Docker will mount the config file in location that vaultenv will read:

services:
  app:
    image: 'my-app'
    secrets:
      - source: vault_config
        target: /etc/vaultenv.conf
      - vault_secrets
    entrypoint:
      - vaultenv
      - docker-entrypoint.sh

secrets:
  vault_config:
    external: true
  vault_secrets:
    external: true

My proposal, above, would mean I could use the default Docker secret mount as the location of the config file by setting the VAULTENV_CONFIG_FILE env var in the Docker image itself. This would avoid having to specify it in every compose file that subsequently uses the image. The compose file would then look like this (which is also easier for newcomers to grok):

services:
  app:
    image: 'my-app'
    secrets:
      - vault_config
      - vault_secrets
    entrypoint:
      - vaultenv
      - docker-entrypoint.sh

secrets:
  vault_config:
    external: true
  vault_secrets:
    external: true

[duijf]

One of the things we currently do is allow cascading behavior of these config files. That fact isn't documented too well in the current README, but vaultenv will look for the config files in this order:

• /etc/vaultenv.conf
• $HOME/.config/vaultenv/vaultenv.conf
• $CWD/.env

vaultenv does not stop once a config file has been found, it will continue looking for the remaining files. If those exist, the config keys overwrite the ones from the top level.

This cascading behavior is very useful for machines which have multiple users/projects.

I don't want to drop that, so we'd need to choose how this extra customization interacts with the current behavior.

---

Instead of VAULTENV_CONFIG_FILE, I would prefer VAULTENV_CONFIG_FILES (and corresponding CLI option). The format would be a comma separated list of config file paths that vaultenv should load in order.

This means that the defaults would be equivalent to these invocations:

$ VAULTENV_CONFIG_FILES=/etc/vaultenv.conf,$HOME/.config/vaultenv/vaultenv.conf,$CWD/.env vaultenv

$ vaultenv --config-files=/etc/vaultenv.conf,$HOME/.config/vaultenv/vaultenv.conf,$CWD/.env vaultenv

We could keep the current behavior as a default and allow users to override the current behavior by passing in custom VAULTENV_CONFIG_FILES.

[orinokai]

Yes, that sounds good, thanks @duijf. It's similar to the docker-compose functionality that cascades docker-compose.yml with docker-compose.override.yml by default, but you can also specify your own cascade with the -f option.

[orinokai]

Do you mind if we keep this open for the time being until #75 is revisited? I'm still really keen for this one, thanks so much 🙏

[duijf]

We did a config refactor in #76, so we can revisit #75 now.

That means this ticket is unblocked.