We are proud to announce the release of Vault 0.3. Vault is a tool for managing secrets. From storing credentials and API keys to encrypting sensitive data, Vault is meant to be a solution for all secret management needs.
Vault 0.3 brings many new features including an
ssh backend, a
backend, new features and improvements to the
transit backend, settable
global and per-mount default/max TTLs, PGP encryption for unseal keys, large
performance improvements for the
generic backend, Duo Multi-Factor
Authentication support, and much more. We cannot possibly list all of the
improvements here, so please see the full
Vault 0.3 CHANGELOG
for more details.
In addition, the entire 0.2 codebase underwent an audit by noted security experts iSEC Partners. Although we cannot share the results, their feedback was valuable, and we intend to continue with regular security audits to ensure that Vault can be trusted with the secrets of even the most cautious of organizations.
As always, a big thanks to our community for their ideas, bug reports, and pull requests.
You can download Vault 0.3 from the project website.
Read on to learn more about the major new features in Vault 0.3.
$ vault write ssh/creds/otp_key_role ip=x.x.x.x Key Value lease_id ssh/creds/otp_key_role/73bbf513-9606-4bec-816c-5a2f009765a5 lease_duration 600 lease_renewable false port 22 username username ip x.x.x.x key 2f7e25a2-24c9-4b7b-0d35-27d5e5203a5c key_type otp
The OTP can be used directly as the SSH password:
$ ssh username@localhost Password: <Enter OTP> username@ip:~$
Or, you can use the new
vault ssh command to automate it:
$ vault ssh -role otp_key_role email@example.com username@ip:~$
ssh backend is another example of how Vault can be used as a security
foundation, beyond just storing secret data. Using the
ssh backend makes
it simpler for organizations to migrate to a zero trust datacenter.
cubbyhole secret backend
is a variation on the
generic secret backend
with an important distinction: the entire space is tied to a particular token,
giving each token a "cubbyhole" for stashing data. When the token expires or
is revoked, its cubbyhole is removed and the data inside is no longer
This enables a number of useful workflows, including some previously difficult authentication scenarios. As an example, suppose you need to give a container a Vault token that it will use to fetch the rest of its secrets and credentials. One common way is to inject the token into the container's environment, with the drawback that this environment is readable by any process with visibility into the container runtime, and may well appear in logs from the container management system, host, or the container itself.
However, in many situations such logs may not be accessible immediately. As a
result, using the
cubbyhole backend, we can take advantage of several of
Vault's security primitives (limited use credentials, credential expiration) to
construct the following authentication workflow:
A process responsible for creating Vault authentication tokens creates two tokens: a permanent (
perm) token and a temporary (
temp) token. The
permtoken contains the final set of policies desired for the application in the container. The
temptoken has a lease duration of 15 seconds and a maximum use count of 2.
temptoken is used to write the
permtoken into the cubbyhole storage specific to
temp. This requires a single write operation, reducing the remaining uses of
The invoked process gives the
temptoken to the container management engine, which starts the container and injects the
temptoken value into the container environment.
The application inside the container reads the
temptoken from the container environment and uses it to fetch the
permtoken from the cubbyhole. This read operation exhausts the
temptoken's use limit, the
$ vault mount-tune -default-lease-ttl=4h -max-lease-ttl=24h secret Successfully tuned mount 'secret'!
$ vault mounts Path Type Default TTL Max TTL Description cubbyhole/ cubbyhole n/a n/a per-token private secret storage secret/ generic 14400 86400 generic secret storage sys/ system n/a n/a system endpoints used for control, policy and debugging
An important part of this feature is that while the per-mount default TTL must
be less than the per-mount maximum TTL (or, if there is no per-mount maximum
TTL, the system maximum TTL), the per-mount maximum TTL overrides the system
value (as such,
root tokens or tokens with appropriate
sudo access) are
required). Combined with the fact that most backends can be mounted at multiple
paths, this allows for a very high degree of administrative flexibility.
See the mounts API documentation for full details.
Note: it is currently up to each backend as to whether it adheres to the set default. Some backends may ignore this, to (for instance) allow per-role defaults instead. However, the configured maximums are enforced by Vault's core, so will always be honored.
PGP Encryption for Unseal Keys
pgp_keys parameter can now be passed when initializing Vault or rotating its
master key, formatted as a string array with base64-encoded PGP keys. The length
must match the
secret_shares parameter. If provided, each output unseal key
will be encrypted with the given public keys; ordering is preserved.
See the init API documentation for more details.
Performance Improvements for Generic
supports the idea of a TTL, but does not actually destroy data when the TTL runs out.
The idea is for writers of data to tell consumers of the data how often they should
check for new values. However, each read on a value set with a TTL would generate
a lease, which became an incredibly costly operation when the number of reads scaled up.
generic no longer generates leases when values are read. A TTL will still be
returned; either the system/mount default, or the TTL set on a particular key, but
this operation does not register a lease in Vault's core. Benchmarks have shown about
a 10x increase in the number of reads per time period that Vault can support as a
Duo Multi-Factor Authentication Support
Vault 0.3 introduces some changes to how it stores data designed to further enhance Vault's capability to detect tampering within its physical store.
As a result, all data written by Vault 0.3 cannot be read by prior versions of Vault. If you think you may want to roll back, ensure you have a stored copy of your storage backend data.
There are a few other deprecations; note that deprecations and breaking changes are announced in advance on the Vault mailing list:
As noted in the Vault 0.3 CHANGELOG, cookie authentication is no longer supported. You must use the
X-Vault-Tokenheader for authentication.
In order to address confusion over the term "lease" being used to describe both a collection of metadata, including a duration, and the duration itself, we are migrating to the term Time-To-Live ("ttl") to describe the duration. At this time, there are no plans to replace the areas in the API using "lease_duration" -- such as in returned JSON responses -- as this is a more verbose but still accurate term; however, we will be deprecating the use of the term "lease" in backends going forward. For 0.3, "lease" is still accepted for the