Setup Hashicorp Vault as a system service

Vault is one of those tools that can’t be automated easily. By design it really shouldn’t be automated. It’s built for storing secrets like passwords, ssh keys, pki certs, etc. in a secure manner. You should spread out the unseal keys among a few people so that not one malicious actor can get at your passwords. So you always need a couple of people to actually unseal, but you can setup privileges to allow specific people/tokens to access secrets. It’s an important piece in your automation tool chain and I prefer to run it as a service. Anytime I need a password/key/secret in terraform it’s as simple as setting up the provider and accessing secrets my token has privileges to.

I didn’t see anywhere in Hashicorp’s documentation on how to setup a systemd service so here are some details. This applies to all systemd systems.

systemd service

I’ve created a simple github gist as a start for your systemd file.

Put this systemd file here: /etc/systemd/system/vault.service

I also keep a pretty basic configuration. I won’t recommend setting up your system without SSL, so get yourself an SSL cert which will match your public/private url/address.

Follow this link to another basic example I’ve created, and make sure to update the address.

Now you can start your service: sudo systemctl start vault

Initializing and unsealing

Once I have my service started I can initialize it. Make sure to set VAULT_ADDR if you haven’t already.

export VAULT_ADDR=https://your.vlt.location.com:8200
vault operator init

You should be greeted with an output of 5 unseal keys and 1 root key. The unseal keys are for unsealing and the root key is for interacting with vault once it is unsealed.

vault operator unseal

You will go through this 3 times until sealed = false.

Where to from here?

Now you have an unsealed running vault as a service. You can find documentation on Hashicorp’s website. I suggest figuring out your organizations policies and procedures around startup/restart/shutdown of the service and unsealing it when needed. Next I suggest you take a dive into policies and design a schema around your secrets. Policies are needed to ensure access controls on secrets. Depending on your needs here you can plugin to something like github or just use the included basic token or user/password authentication. These details are highly dependent on what your organization needs.

If you liked this post come check out my thoughts on popular configuration management tools