Mitchell Hashimoto follows up Vagrant with Vault key encryption

Vault not only stores encryption keys and credentials, but generates them automatically for use in services and APIs

vault safe lock security
Current Job Listings

After creating the Vagrant devops tool, Mitchell Hashimoto has been anything but complacent. He's launched several projects, including the Atlas end-to-end management system for controlling the open source projects used during a product's lifecycle.

Now, Hashimoto sets his sights on a new problem: How enterprises can securely manage secrets or access keys for APIs, applications, or microservices without hard-coding or hand-rolling a solution.

Under lock and key(s)

Vault, as HashiCorp's new open source product is called, generates and keeps such data in an encrypted key/value store. Secrets stored in the vault have a lifetime, or a lease, after which the secret automatically expires and is revoked, making it easy for admins to grant provisional access to a user or app.

All the behaviors within the system are available through an HTTP API, generate an audit trail, are governed by access control policies, and can be governed by multiple authentication methods. (The current 0.1 version supports GitHub as an authentication method out of the box, with "many more" to be added later.) Master keys for the vault are split between multiple individuals (three, by default) so that it's impossible for any one person to decrypt the data.

Beyond serving as an encrypted repository, Vault can also function as an on-demand generator for such credentials. An example, as described by the company: If an application needs access to an S3 bucket in AWS, it can ask Vault for credentials, and Vault will generate a key pair automatically. This way, the credentials do not have to be stored or hard-coded, and they can be rotated automatically or even produced as one-time tokens.

Vault can also be run in high-availability mode, although only one of its back ends currently supports this. Instances of Vault can also be booted in "dev" mode as a way to manually disable many of the production-level security measures that may make it easier for a developer to deal with it.

A Vault of your own

Vault might draw comparisons to the kinds of key-management solutions provided by Amazon or Microsoft, especially given how Vault can be used to manage key pairs for cloud services. The key-management services have the advantage of convenience, especially if you're already heavily invested in AWS or Azure, and want to leverage the integration without having to build too much of it manually.

Another major difference: The products are backed by HSM (Hardware Security Module) appliances, meaning the keys are not even accessible to those hosting the service. Vault's makers go out of their way to say that Vault isn't meant to replace HSMs, but rather work in conjunction with them if needed.

The one area where Vault stands most apart from those services is that it's an open source product with no ties to any particular cloud vendor. That should be an advantage to both enterprises leery of committing themselves to infrastructure that isn't theirs and to companies setting out to create their own infrastructure from scratch.