HashiCorp Vault 0.6

HashiCorp Vault 0.6

Jun 14 2016 Jeff Mitchell

We are proud to announce the release of Vault 0.6. Vault is a tool for managing secrets. From API keys and encrypting sensitive data to being a complete internal CA, Vault is meant to be a solution for all secret management needs.

This release contains major new features, some new secure workflow enhancements, and many improvements and bug fixes. A major focus was token management and token/authentication workflows.

In Detail:

In Brief:

(Some of these features appeared in 0.5.1 and 0.5.2, however they were not discussed in previous blog posts.)

Please see the full Vault 0.6 CHANGELOG for more details. Additionally, please be sure to read the upgrade information at the end of this post.

As always, a big thanks to our community for their ideas, bug reports, and pull requests.

Read on to learn more about the major new features in Vault 0.6.

Token Accessors

When creating tokens, two values are now returned: the token itself and an accessor.

$ vault token-create -policy=default Key Value

token 82c5fb97-da1b-1d2c-cfd5-23fa1dca7c85 token_accessor dd256e17-b9d9-172d-981b-a70422e12cb8 token_duration 2592000 token_renewable true token_policies [default]

The accessor can be used to perform lookup and revocation on a token without knowledge of the token itself, either via auth/token/lookup-accessor/auth/token/revoke-accessor or via the -accessor flag to the respective CLI commands. The lookup function, when using an accessor, does not return the token ID.

$ vault token-create -policy=default Key Value

token ff999148-077e-2629-8d9a-cb0a7b97e811 token_accessor 8c243823-5820-ff8f-f641-6999290c60c0 token_duration 2592000 token_renewable true token_policies [default]


» token-create command with response wrapping


$ vault token-create -policy=default -wrap-ttl=60s Key Value

wrapping_token: 7a39125a-2001-be9b-e363-3ba85a16c311 wrapping_token_ttl: 60 wrapping_token_creation_time: 2016-06-14 06:02:11.171558903 +0000 UTC wrapped_accessor: ed96a7ae-dfdb-3c09-0a60-a02b53dfe6b2


» Unwrapping the wrapped response


$ vault unwrap 7a39125a-2001-be9b-e363-3ba85a16c311 Key Value

token d878b2ed-564e-0790-4154-67bcf7386268 token_accessor ed96a7ae-dfdb-3c09-0a60-a02b53dfe6b2 token_duration 2592000 token_renewable true token_policies [default]


» Detection of invalid (previously used) token


$ vault unwrap 7a39125a-2001-be9b-e363-3ba85a16c311 error reading cubbyhole/response: Error making API request.

URL: GET Code: 400. Errors:

  • permission denied

    As can be seen from the example, when the wrapped response contains a token, the token's accessor is provided with the wrapping information. This allows a privileged caller generating tokens to easily keep track of which accessor corresponds to which client, in case the token must be revoked.

    Because response wrapping can be used with almost any Vault request, it can be used to provide extra transport security for any secret:


» K/V (generic) backend


$ vault write secret/foo bar=baz Success! Data written to: secret/foo

$ vault read -wrap-ttl=60s secret/foo Key Value

wrapping_token: 3a63ff9f-1c38-af43-0a85-dc1155f2469d wrapping_token_ttl: 60 wrapping_token_creation_time: 2016-06-10 13:46:14.155857566 -0400 EDT

$ vault unwrap 3a63ff9f-1c38-af43-0a85-dc1155f2469d Key Value

refresh_interval 2592000 bar baz


» Transit backend


$ echo "bar" | base64 | vault write transit/encrypt/foo plaintext=- Key Value

ciphertext vault:v1:j4Z1/6WLK+snlhIyooxa1zW0yEmBqFSfZTL88bN/Qt4=

$ vault write -wrap-ttl=60s transit/decrypt/foo ciphertext="vault:v1:j4Z1/6WLK+snlhIyooxa1zW0yEmBqFSfZTL88bN/Qt4=" Key Value

wrapping_token: e93a78ec-cced-dc94-d1f8-d71e84faddde wrapping_token_ttl: 60 wrapping_token_creation_time: 2016-06-07 15:59:18.251657838 -0400 EDT

$ vault unwrap -field=plaintext e93a78ec-cced-dc94-d1f8-d71e84faddde | base64 -d bar

AWS EC2 Authentication Backend

The AWS EC2 Authentication Backend provides a way for EC2 instances to automatically authenticate to Vault and retrieve a Vault token. An AMI baked with a supporting client can authenticate without any user intervention or configuration management required.

The backend works by using AWS as a trusted third party. Specifically, AWS provides instance metadata signed with their private key and verifiable with their published public key. At a high level, the backend verifies the given metadata's authenticity, checks that the instance ID has not been used before (a principle known as TOFU, or Trust On First Use), and verifies that the instance is in a running state. The backend also accepts a client-specified nonce value that can be used by the client to fetch new tokens when the initial token expires, even while other clients attempting to reuse the metadata are denied access.

At a low level, various modifications are supported to fit into the security policy and workflow of a wide variety of organizations. Please see the documentation for details.

In order for an instance to authenticate, a client running in the instance must actually contact Vault and provide the necessary information through Vault's API. For Vault Enterprise customers, HashiCorp has built a standalone binary that does exactly this, allowing for easy deployment of this workflow. The client keeps the provided token renewed and, upon token expiration, reauthenticates to fetch a new token.

The Vault Enterprise client binary is simply a consumer of the backend API and does not rely on any behavior within Vault that is not open source. Organizations that are not Vault Enterprise customers can build their own client if they desire, or can contact HashiCorp for information on Vault Enterprise.

Other Features

There are too many new features and improvements in this release to describe all of them in depth, so a few more are covered below in brief:

  • Codebase Audit: Vault's 0.5 codebase was audited by iSEC Partners. (The terms of the audit contract do not allow us to make the results public.)

  • Consul Data Store Health Checks: The Consul data store will automatically register a vault service and perform its own health checking. By default the active node can be found at active.vault.service.consul and all with standby nodes are standby.vault.service.consul. Sealed vaults are marked critical and are not listed by default in Consul's service discovery. See the documentation for details.

  • Listener Certificate Reloading: Vault's configured listeners now reload their TLS certificates and private key when Vault is sent a SIGHUP, allowing for online rotation of Vault's certificates without needing to shut down Vault and unseal it again.

  • MSSQL Secrets Backend

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now