Using Hashicorp's Vault for Secrets Management

Don't keep secrets in files or your code repository. This tutorial is an introduction to storing secrets in a secrets manager using Hashicorp's Vault.

There are various different secrets managers available, some are available on cloud platforms and others can be run as a service locally on one of your machines. The advantage of using a secrets manager is that it becomes a centralized store of secrets, complete with access control to limit which machines and users have access to the secrets. Typically the kinds of secrets that you want to store are things like passwords, api keys, certificates and other sensitive small pieces of information.

What you would prefer to not do it store them in plain text in some file locally on the machine or as some password that is stored in your repository. There are stories of people getting backed because they stored a database password on github in a public repository – don't be like them!

This outline describes a method that would allow you setup your own secrets management service that would allow you to control what hosts are able to connect to your secrets store using certificates and a DNS. There are more advanced methods where a one time token can be issued to applications on startup (this is a more advanced method and I'll be leaving this outside the scope of this discussion).

Setting up Private Key Infrastructure with Vault

Using host certificates is a safe way of connecting to vault as there is a chain of trust built between the machine and vault. When connecting to vault it is advisable to use DNS to link hosts to names as this gives you control of what hosts are able to join the network. The second is given the name of the host, you will be able to create signed certificates linked to the host name that can be used for verification that this request is indeed coming from your host.

Using Certificates to Login to Vault

Hosts will be able to login to vault once issued a certificate. The certificate can be presented to vault to be issued an access token which now has a fixed validity time before the token expires and can be refreshed with the certificate (so long as the certificate is valid).

Once this is achieved, you'll now be able to connect to vault and have access to the API as defined by the level of access depending on your ACL.