Skip to content

Releases: channable/vaultenv

v0.11.0 - "Destination Unknown"

23 Oct 10:31
Compare
Choose a tag to compare

Vaultenv has gained support for reading connection configuration options from the standard VAULT_ADDR environment variable.

With this release, we have also started shipping fully static binaries for Linux.

VAULT_ADDR support

Vaultenv already had support for the following CLI options and environment variables to configure connection information:

  • --host or VAULT_HOST
  • --port or VAULT_PORT
  • --[no-]connect-tls or VAULTENV_CONNECT_TLS

With this release, we also add support for reading this information from the VAULT_ADDR environment variable. The old configuration options still work and will remain supported.

Please refer to the README for details (most notably on how precedence and conflicts in these options are handled).

Static binary releases

The Linux binaries that we used to provide were coupled to a version of libc. This meant users had to compile vaultenv from source if they were on a distro with an older libc than the one we compiled Vaultenv with.

From now on, the Linux binaries we distribute are fully static, meaning they are no longer coupled to a version of libc. We ship a static binary containing MUSL and integer-simple.

v0.10.0 - "Sparkles, cake, sparkles!"

07 Jun 15:56
Compare
Choose a tag to compare

Vaultenv now has support for version 2 of the KV secret engine. This support is automatic. Vaultenv finds out automatically which version of the KV secret backend you're using. There is nothing to configure.

Backwards incompatible changes

To make this automatic detection of the version of your secret engine possible, vaultenv now makes an extra HTTP request. This request goes to the /sys/mounts endpoint.

The purpose is to find out which version of the KV engine you are running and change the request and response parsing logic accordingly. Make sure that your security policy allows these requests before upgrading.

CI upload is a bit bugged, so we only have a binary from Ubuntu 18.04 available for you. It links against a relatively new version of libc, so it might not work for you.

v0.9.0 - "Interactive Improvement"

01 Nov 09:55
Compare
Choose a tag to compare

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.

v0.8.1 - "Path Pretense"

24 Oct 14:24
Compare
Choose a tag to compare

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

The binaries on this page are provided for convenience. If you encounter any linking issues, you might need to build from source. Please refer to the README for instructions.

Search Path option

This release features a tiny quality of life option: searching PATH for executables. Pass the --use-path flag to vaultenv to enable.

This feature is disabled by default for backwards compatibility.

v0.8.0 - "Mountain Rescue"

07 Sep 14:04
Compare
Choose a tag to compare

(The filenames above are weird. GitHub has a bug in their uploader, but it's better than nothing)

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

The binaries on this page are provided for convenience. If you encounter any linking issues, you might need to build from source. Please refer to the README for instructions. One user reported problems with the latest glibc version.

Specify mount points

Vaultenv 0.8.0 now supports configuration of the mountpoint it fetches secrets in Vault from. Prior to this release, Vaultenv defaulted to secret/ for this.

In particular, this allows users to use Vaultenv for the dynamic secret engines that Vault supports.

The secret file format has changed to accommodate for the configuration of this information. However, the changes in this release are fully backwards compatible as far back to to and including 0.6.0.

Secret format upgrade guide

Version 1 of the format won't go anytime soon. However, upgrading is easy!

Let's say you have the following secrets file:

third-party#foo
another-party#bar

You can upgrade to Version 2 of the format by changing this to:

VERSION 2

MOUNT secret
third-party#foo
another-party#bar

This has exactly the same behavior.

Backwards incompatible changes

Vaultenv now exits with a nonzero exit code on network and parsing errors. This may break or change the behavior of existing scripts (or systemd service files) that use Vaultenv's exit code for their operation.

v0.7.1 - "Tiny Tweak"

08 Jun 11:55
Compare
Choose a tag to compare

Vaultenv is a CLI utility that fetches secrets from HashiCorp Vault and makes them available under environment variables. This patch release contains no code changes, but does contain a tweak to the compilation flags.

The binaries on this page are provided for convenience. If you encounter any linking issues, you might need to build from source. Please refer to the README for instructions.

Run on Single Threaded Runtime by default

Vaultenv now uses the Single Threaded GHC runtime, instead of the threaded by default. Quick measurements showed that for our application, this is slightly faster than using the threaded runtime, presumably since no overhead of creating OS threads is incurred.

This also works around a bug in the threaded RTS where vaultenv would error with a message of failed to create OS thread: Resource temporarily unavailable.

v0.7.0 - "Configuration Nation"

28 Feb 13:23
Compare
Choose a tag to compare

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

Configuration through environment variables

Most vaultenv arguments can now be configured through environment variables. Previously, vaultenv only respected the value of the VAULT_TOKEN environment variable. The new supported environment variables are:

  • VAULT_HOST
  • VAULT_PORT
  • VAULTENV_SECRETS_FILE
  • VAULTENV_CONNECT_TLS
  • VAULTENV_VALIDATE_CERTS
  • VAULTENV_INHERIT_ENV
  • VAULTENV_RETRY_BASE_DELAY_MS
  • VAULTENV_RETRY_ATTEMPTS
  • VAULTENV_LOG_LEVEL

The only things not configurable through environment variables are the command to execute and the arguments to pass to it.

It often happens that you have multiple services on the same machine which need secrets from Vault. If you don't use the default options, it could be a slight hassle to change the vaultenv connection options for multiple services. With this change, you could configure e.g. a systemd service through an EnvironmentFile:

# /etc/vaultenv.conf
VAULT_HOST=vault.service.consul
VAULT_PORT=4242
VAULT_TOKEN=<your token here>
VAULTENV_VALIDATE_CERTS=false

With a service definition like:

[Unit]
Description=My service

[Service]
EnvironmentFile=/etc/vaultenv.conf

ExecStart=/usr/bin/vaultenv \
  --secrets-file /etc/secrets.d/my-service.secrets \
  -- /usr/bin/my-service ARGS

[Install]
WantedBy=multi-user.target

With this setup, systemd will ensure the environment variables defined in /etc/vaultenv.conf are set before the ExecStart command is called. This means you don't have to provide any non-default config settings in all your
systemd services.

Log levels

Vaultenv supports configurable log-levels through --log-level and VAULTENV_LOG_LEVEL. On info, we currently print the config on startup. On error, which is the default, we print all error cases that we previously did.

v0.6.0 - "eval($release_name)"

12 Feb 16:26
Compare
Choose a tag to compare

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

The binaries on this page are provided for convenience. If you encounter any linking issues, you might need to build from source. Please refer to the README for instructions.

Enhancements

  • Make certificate validation configurable through --no-validate-certs
  • The retry policy is now configurable through two new CLI flags: --retry-base-delay-milliseconds and --retry-attempts
  • Vaultenv supports reading the Vault token from the environment through $VAULT_TOKEN.

Performance

  • Vaultenv now only makes one HTTP request per secret. This will lead to better performance when users want multiple key/value pairs from a secret.

Fixed bugs

  • Added the netbase package to the dependencies of our Debian packages. This fixed an error while running vaultenv from Docker containers. (PR #29)

v0.5.0 - "Environmental"

04 Sep 12:38
v0.5.0
7d16472
Compare
Choose a tag to compare

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

The binaries on this page are provided for convenience. If you encounter any linking issues, you might need to build from source. Please refer to the README for instructions.

New features

  • Add --no-inherit-env option.

Breaking changes

  • Fail on duplicate environment variables.

v0.4.2 - "Utrecht"

06 Jul 14:12
Compare
Choose a tag to compare

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

The binaries on this page are provided for convenience. If you encounter any linking issues, you might need to build from source. Please refer to the README for instructions.

Breaking changes

  • Vault now connects over TLS by default. Use --no-connect-tls to disable.