Managing your secrets in Production using HashiCorp’s Vault


One of the biggest problems faced by DevOps / Infrastructure Administrators is how to manage the secrets (including API keys, user / passwords, etc) in such a way that becomes easy to rotate and revoke if and when required.

Another issue comes in when a developer needs access to production environment to debug a critical issue that is occurring in production.

To tackle these issues, we either end up writing our own utilities or creating very confined policies for developers and have to monitor them very closely. Another solution that we might go for is creating a team of senior / trusted developers to have access to production for debugging purpose.

HashiCorp’s Vault

Vault tries to tackle the above mentioned issues and much more and provides a standard way for teams to understand the process of integrating Vault in different steps of CI / CD (continuous integration / continuous delivery) pipeline.

Vault can also be used to create temporary credentials (depending on the backend) on the fly with specified lease time.

I will try to go through some basics of how Vault works and will perform some basic secret handling using Vault

How Vault works

Vault is a secret management solution designed by HashiCorp. Vault can be considered as something similar to a bank locker which is protected by multiple systems.

By default when we start vault it is locked and sealed. We will cover the unsealing / unlocking part in a bit detail later in this article.

Vault uses Shamir’s Secret Sharing Algorithm for its unsealing part. This means that you need a defined number of keys (we will discuss this later) to unseal the vault. This method makes sure that no one person is responsible to open vault.

I will try explain more about vault as we progress in this article.

Installing Vault

Download Vault’s binary from here for the platform you will be working on.

mudasir:~ $ curl -o

Once the download is complete, unzip to the downloaded file and you will get a single binary. We will need to copy this binary in some location which is present in your $PATH

mudasir:~ $  cp vault /usr/local/sbin/

Now the vault’s binary isis our $PATH, so we can simply run vault command from CLI to test if it is working or not

mudasir:~ $ vault version

Vault v0.6.4 (‘f4adc7fa960ed8e828f94bc6785bcdbae8d1b263’)

Starting Vault Server

Now we will start vault server. For practice and very basic use of vault, you can start vault in Dev mode.

When you start vault server in dev mode, it automatically starts vault in unsealed state and it is completely an in-memory process, so nothing gets written / persisted anywhere. Vault server’s dev mode provides you with single UnSeal Key and the Root Token which we will use in further interaction with Vault. To start vault server in dev mode

NOTE: Never use Dev Mode in production

mudasir:~ $ vault server -dev

==> Vault server configuration:

Backend: inmem
Cgo: disabled
Listener 1: tcp (addr: “”, cluster address: “”, tls: “disabled”)
Log Level: info
Mlock: supported: false, enabled: false
Version: Vault v0.6.4
Version Sha: f4adc7fa960ed8e828f94bc6785bcdbae8d1b263

==> WARNING: Dev mode is enabled!

In this mode, Vault is completely in-memory and unsealed.
Vault is configured to only have a single unseal key. The root
token has already been authenticated with the CLI, so you can
immediately begin using the Vault CLI.

The only step you need to take is to set the following
environment variables:

export VAULT_ADDR=’′

The unseal key and root token are reproduced below in case you
want to seal/unseal the Vault or play with authentication.

Unseal Key: ew0zbQvsBavHg4885G21ECUjpNPyUlTW3DLyIdsRrN0=
Root Token: 3f2f21f5-e502-00bf-80a9-5de6d2ba8201

==> Vault server started! Log data will stream in below:

2017/02/03 18:41:09.028443 [INFO ] core: security barrier not initialized
2017/02/03 18:41:09.029439 [INFO ] core: security barrier initialized: shares=1 threshold=1
2017/02/03 18:41:09.029820 [INFO ] core: post-unseal setup starting
2017/02/03 18:41:09.036411 [INFO ] core: successfully mounted backend: type=generic path=secret/
2017/02/03 18:41:09.036809 [INFO ] core: successfully mounted backend: type=cubbyhole path=cubbyhole/
2017/02/03 18:41:09.037283 [INFO ] core: successfully mounted backend: type=system path=sys/
2017/02/03 18:41:09.037345 [INFO ] rollback: starting rollback manager
2017/02/03 18:41:09.040014 [INFO ] core: post-unseal setup complete
2017/02/03 18:41:09.041368 [INFO ] core: root token generated
2017/02/03 18:41:09.041374 [INFO ] core: pre-seal teardown starting
2017/02/03 18:41:09.041392 [INFO ] rollback: stopping rollback manager
2017/02/03 18:41:09.041403 [INFO ] core: pre-seal teardown complete
2017/02/03 18:41:09.041457 [INFO ] core: vault is unsealed
2017/02/03 18:41:09.041469 [INFO ] core: post-unseal setup starting
2017/02/03 18:41:09.041588 [INFO ] core: successfully mounted backend: type=generic path=secret/
2017/02/03 18:41:09.041599 [INFO ] core: successfully mounted backend: type=cubbyhole path=cubbyhole/
2017/02/03 18:41:09.041687 [INFO ] core: successfully mounted backend: type=system path=sys/
2017/02/03 18:41:09.041733 [INFO ] rollback: starting rollback manager
2017/02/03 18:41:09.042199 [INFO ] core: post-unseal setup complete

Keeping Secrets with Vault

Now we will go through on writing and reading secrets from vault. For this open new terminal window

mudasir:~ $ export VAULT_ADDR=’′

mudasir:~ $ vault write secret/foo vaule=bar
Success! Data written to: secret/foo

mudasir:~ $ vault read secret/foo
Key             	Value
---             	-----
refresh_interval	768h0m0s
vaule           	bar

Vault comes with a built in API which can be utilized to perform all the actions which CLI does. To use API, we will need the Rook Token which we got when we started the vault server in dev mode.

mudasir:~ $ curl -XGET -H "X-Vault-Token: 3f2f21f5-e502-00bf-80a9-5de6d2ba8201"
	"request_id": "6117e0ce-87c7-cfd3-af3a-ce2f02dfb87e",
	"lease_id": "",
	"renewable": false,
	"lease_duration": 2764800,
	"data": {
		"vaule": "bar"
	"wrap_info": null,
	"warnings": null,
	"auth": null

This is the most basic example and will give you guys some idea about vault and most probably will get you guys started on playing with vault.

In my coming posts, I will show how to use different Auth Backends and Secret Backends of vault.

Categories: Uncategorized

Tags: ,

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: