Skip to content

Releases: channable/vaultenv

v0.16.0 - "I am always right"

06 Jul 07:22
Compare
Choose a tag to compare

This release contains some fixes and minor enhancements, in addition to a new feature.

What's Changed

New Contributors

Full Changelog: v0.15.1...v0.16.0

v0.15.1 - "Sharing is caring"

28 Jun 14:23
Compare
Choose a tag to compare

This is a bugfix release to v0.15.0 with one minor change:

  • Github- and Kubernetes authentication will now inject the VAULT_TOKEN, unless blacklisted. This allows both authentication methods to be used as a complete replacement for the token auth.

v0.15.0 - "A token of my appreciation"

13 Jun 14:36
Compare
Choose a tag to compare

This release adds two new authentication methods to Vaultenv:

  • GitHub authentication
  • Kubernetes authentication (thanks @ruuda!)

The former is meant to be used in a development environment, and works
with a personal access token. The latter is meant to be used in a
Kubernetes cluster.

This release also updates some dependencies.

v0.14.0 - "It's the little things"

15 Oct 08:18
Compare
Choose a tag to compare

This release fixes some minor issues in Vaultenv:

  • Vaultenv will now enable "line buffering" mode for its output, which prevents issues with log messages getting mixed up or delayed if e.g. running under Systemd or Kubernetes.
    This was fixed by @ruuda in #115.

  • When printing the configuration with --log-level info Vaultenv will now correctly specify the unit for the base delay (milliseconds), where it previously printed an ambiguous plain number.
    This was added by @ruuda in #113.

This release also contains fixes to make running the integration tests more reliable / work in more Linux environments.
This was contributed by @ruuda in #114.

v0.13.3 - "Staying Alive"

06 Jul 13:53
Compare
Choose a tag to compare

This release reduces server load while loading large secrets files.

This release should enable connection reuse on the requests to vault. The support for this was technically already in place, but because all requests were sent simultaneously, no actual reuse was done. The new release limits the number of concurrent requests to 8 by default, which can be overridden using the --max-concurrent-requests option VAULTENV_MAX_CONCURRENT_REQUESTS environment variable. Setting this value to 0 restores the old behaviour.

In addition, minor improvements were made to the Vault response parser.

v0.13.2 - "Secret Agent"

14 Oct 14:43
8e0497a
Compare
Choose a tag to compare

This release should allow Vaultenv to be used in conjunction with Vault agent.

Requests to vault now have the X-Vault-Request header set, and the vault token has become an optional parameter. If the parameter is not set, the vault requests are sent without and Vault Agent is expected to add a token using auto auth.

As a result, a misconfiguration regarding missing tokens that would previously be detected locally are now detected by the Vault server instead. Vaultenv should still exit once it receives such a response.

In addition, VAULT_ADDR is now allowed without port. The port defaults to 80 when the scheme is http:// and 443 when the scheme is https://.

v0.13.1 - "Owned by me and not by thee"

03 Mar 15:49
Compare
Choose a tag to compare

This release fixes a bug in the provided Debian package.

The packages of 0.13.0 and earlier versions were not built with the fakeroot
utility, which caused the installed package files (/usr/bin/vaultenv and
/etc/secrets.d/) to be owned by the local user with uid 1000 instead of by root.
We've now adjusted the build script to correctly use fakeroot, the package will
also automatically correct this issue by changing the owner and mode of
/usr/bin/vaultenv and /etc/secrets.d when upgrading from an earlier version.

There are no changes to the code of the Vaultenv binary, except for an increase in
the version number.

v0.13.0 - "If at first you don't succeed"

19 Feb 13:46
Compare
Choose a tag to compare

This release fixes a bug in Vaultenv's retry behaviour.
The bug caused Vaultenv to crash immediately if it failed to retrieve
the mount information or a secret from the Vault server, while it was
supposed to retry fetching that information.

If Vaultenv fails to fetch the mount info or one or more secrets it will
now correctly retry fetching that information according to the
configured retry policy. This retry policy is (and was) configurable
with the options --retry-base-delay-milliseconds /
VAULTENV_RETRY_BASE_DELAY_MS and --retry-attempts /
VAULTENV_RETRY_ATTEMPTS.

Vaultenv will now also redact the used Vault token before outputting an
error message when a secret or the mount info cannot be fetched within
the retry period.

v0.12.0 - "Need to Know"

15 Jan 11:59
Compare
Choose a tag to compare

Vaultenv now supports removing specific variables from the environment before
executing the wrapped command, allowing the user to selectively inherit the
parent environment (instead of completely or not at all).

This behaviour can be enabled by passing the --inherit-env-blacklist
option, setting the VAULTENV_INHERIT_ENV_BLACKLIST environment
variable, or setting the VAULTENV_INHERIT_ENV_BLACKLIST option in a
Vaultenv configuration file. The value of the option or variable should
be a list of names of environment variables to remove, separated by
commas.

Vaultenv will remove the variables from the environment of the command to
execute if the variable has a name that exactly matches a name in the
blacklist. Vaultenv will also remove variables retrieved from Vault if the name
of the variable matches a name on the blacklist.

The blacklist has no effect if --no-inherit-env is used, and the option will
be silently ignored.

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.