Vault setup as a system service

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.

Initializing and unsealing

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.