What news from AWS re:Invent last week will have the most impact on you?
Amazon Q, an AI chatbot for explaining how AWS works.
Super-fast S3 Express storage.
New Graviton 4 processor instances.
Emily Freeman leaving AWS.
I don't use AWS, so none of this will affect me.
Cloud Native Ecosystem / Microservices

Using Vault to Manage Your App’s Secrets

May 14th, 2015 11:08am by
Featued image for: Using Vault to Manage Your App’s Secrets
Feature image via Flickr Creative Commons.

Vault is a new tool for managing and encrypting your app’s secrets. It can be used to keep everything from your API tokens, to your database passwords, safe and secure. Historically, secret management has been a very involved process, and it was far too easy to inadvertently introduce security issues. Vault is here to make this process simpler. Here are eight reasons why Vault is worth considering for your next project.

1. It’s Stack Agnostic

Storing secrets has long been a platform-specific affair, with little carry over between technology stacks. You might use secrets.yml for your Rails projects, but that doesn’t help you with your Node projects. More often then not, though, developers end up rolling their own ad hoc solutions for managing secrets. Vault can be used across all technologies in your stack, and prevents you from having to constantly reinvent the wheel.

2. It’s by the Brains at Hashicorp

Hashicorp has been providing amazing open source tools for some time now. Packer, Serf, Consul, Terraform, and the very popular Vagrant, are all impressive tools. Granted, a history of great products doesn’t guarantee all future products, but there is definitely every reason to believe in Vault, given Hashicorp’s prior successes.

3. Environment Variables can be Painful

Storing your configuration outside of your code is one of the pillars of a 12 factor app. The gold standard for this has been environment variables. While a workable solution, they do have some baggage that comes along with them. One is that, while it’s fairly manageable to control which environment variables are exported in a given environment, it is harder to guarantee the absence of other variables. Another issue is the global nature of environment variables can make them somewhat unpredictable. Vault lessens your dependency on environment variables by allowing you to store such configuration data in their key value system instead.

4. It’s Battle-Tested

While it’s new to the outside world, Vault has been running at production scale over at Hashicorp for sometime now. The source code for Vault is readily available for inspection over at Github, and it can be verified that Vault has some strong test coverage. This isn’t some hacked together weekend project.

5. It Makes a Lot of Sense With a Microservices Architecture

Vault meshes very nicely with microservice-based architectures. I’ve made a few projects with Vault, and having all my components talk to one service that handles credentials — and handles only credentials — made a lot of sense. In microservice-based architecture, you’ll have a service for your mailing, for your front-end, for order processing, etc … so why not have one service that handles all of your secrets? All of your other services can get their credentials through Vault’s REST API, and you won’t have to encode secrets into any other of your services. This is a pretty big win.

6. Dynamically Generated Credentials

It’s a common practice to issue credentials on a per user basis, instead of sharing one set of credentials across all users. The logical next step is to issue credentials on a per transaction basis. These dynamically created credentials can be revoked immediately after completing your transaction. This provides an even greater promise that your credentials won’t be compromised, and provides even further damage mitigation in the unlikely event of a breach.

7. Clean API

Vault is very well thought out; it hits that rare combination of being simple to use and understand, without limiting its power or use cases. In my experience, it doesn’t take long to go through the docs/tutorials, and quickly start feeling like a Vault power user.


While all the above is great — as is typically the case with software — certain tradeoffs were made in Vault’s design, and there are some limitations. While there are many benefits to being able to run Vault as a service, this does lead to increased infrastructure costs, and the associated pains of managing that infrastructure. Additionally, not all of Vault’s benefits are available for all use cases. For example, dynamically generated secrets can only integrate with a limited number of other services. Also, Keywhiz by Square is another big player in this area that is worthy of attention. The biggest fundamental difference between Vault and Keywhiz, is that while Vault exposes secrets over an API, Keywhiz uses a FUSE filesystem. Vault wrote a nice and fairly objective writeup on the comparison. Lastly, if you are working with Chef or a related tool, it’s probably easier initially to use their integrated solution than it is to wire it up to Vault.

Revolutionary new technology is often revered with with a combination of awe and trepidation. While it makes sense to be cautious about adding new things to your tech stack, vault has a very compelling use case in an underserved area of computing. Give it a go for your next project; however, there’s a good chance you’ll be tempted to migrate all of your projects over to vault later. For those who are interested, be sure to checkout the official Vault tutorial.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.