Skip to content

v0.9.0 - "Interactive Improvement"
Compare
Choose a tag to compare
@duijf duijf released this 01 Nov 09:55
· 185 commits to master since this release
v0.9.0
1dd681f

Vautlenv is a CLI utility that fetches secrets from HashiCorp Vault and makes them available under enviornment variables.

This release focusses on making Vaultenv easier to use interactively. By supporting reading configuration from files, vaultenv should require less CLI arguments or environment settings.

This is a nice improvement, but it is backwards incompatible in a small amount of cases. Read on for details.

Note that the binaries on this page are provided for convenience. If you encounter linking errors, please compile from source. Consult the README for instructions.

Configuration files

Vaultenv now consults the following files for configuration options:

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

The files are read top to bottom. Configuration options from files down the list override options from before.

These files follow the .env format, as popularized by the dotenv Ruby gem. These have similar syntax to SystemD environment files. Under the hood, vaultenv treats these in the exact same way as it treats
the configuration via environment variables. All the options are supported.

An example which also shows off the usecase for the different files:

Below is a system wide config. Useful if you always connect to the same Vault for development secrets:

# /etc/vaultenv.conf
VAULT_HOST='vault.yourcompany.internal'
VAULT_PORT='443'

To avoid having to specify a token on every invocation, you can configure (per-user) tokens in $HOME. Make sure to chmod 600 this file:

# $HOME/.config/vaultenv/vaultenv.conf
VAULT_TOKEN='a32c9e2f-23d2-4bdb-a77e-61349202272a'

Different projects require different sets of secrets. Therefore different secret files. You can add project specific .env files where you specify a different secrets file:

# $HOME/some-project/.env
VAULTENV_SECRETS_FILE='./config/project.secrets'
VAULTENV_USE_PATH='true'

Then you can launch any executable from your project directory with the relevant secrets from your project by just prefixing it with vaultenv.

Note that none of this is required to get started with vaultenv. You can set all of these options on the CLI. It is just a nice improvement for interactive use-cases.

Backwards compatibility

The addition of these config files is a backwards incompatible change. If these files already happen to exist on your filesystem in these locations, then it may change the behavior of Vaultenv from what you're used to seeing.

Normally, this is a mostly technical argument, but the chances of this are higher than infinitesimal because we suggested the use of /etc/vaultenv.conf for machine wide settings in systemd services in release v0.7.0.

We feel like it's worth breaking backwards compatibility in (what we expect are) a small amount of use-cases. Putting this behavior behind a flag would mean always having to type something like vaultenv --enable-config-files CMD.

Assets 4
Loading