Additional Security Considerations for Vault

Posted on April 3, 2020 in Sysadmin

Things to consider with a personal Vault instance, and additional layered security

When using Hashicorp's Vault in a professional, shared environment there are some parts of the tool that make more sense versus using it in a personal environment. I am going to break down my decision making process for how I'm using my personal Vault instance with regards to several configuration options.

Unlock Key Sharding

By default, whenever your Vault is started or restarted it will be sealed. To unseal it, a master key is required. Rather than storing this singular master key, Vault has a mechanism for creating key shards and requiring a certain threshold or number of the shards to recreate the master key and unseal the Vault. In production in a corporate setting, as an example, you may have 5 administrators with key shards, requiring any 2 to enter their shard to unseal the Vault in the event of a restart (intentional or not). This means if a single administrator left the company, while you should still re-key your Vault instance (which you can do at any time, I might add), you could seal the Vault until you were ready to make a decision about what's next and the admin who left couldn't unseal it on their own, thus they would not have access to any of the secrets in Vault. I will also note that you shouldn't keep any root tokens (we'll talk a bit about tokens later) laying around for Vault beyond initial setup, and it requires a quorum of users with unseal keys to create a root token at any future point if necessary. If your key threshold was 1, any administrator with an unseal key could create a root token and make any change to any aspect of Vault - configuration, adding or removing secrets, etc.

But, what about for a personal instance of Vault intended to be used by one person? The sharding no longer makes a lot of sense. At least as of my writing this, there isn't a way to disable the seal/unseal functionality, and I'm not sure you would want to. You want to use Vault as a password manager to have the convenience of the web UI, but without the security implications of using something non-self hosted and cloud-based, so you also don't want to be in a situation where you have to fumble through 5 unlock keys yourself to unlock your Vault after the VPS it's running on reboots because of a hardware issue.

As far as I came up with, there are two approaches to handling this. You have to choose the solution that is best for you based on the level of difficulty you want to go through to unlock the Vault, weighing the pros and cons. You could have one key with a threshold of one key to unlock, and you could GPG encrypt that key somewhere that is easily accessible. This is probably the most sane and most convenient solution, especially if it's accessible from your laptop, phone, etc. If at any point you see the Vault is sealed, you GPG decrypt the unseal key, enter it, and move on. But I'm me, and I'm a little paranoid. So the other solution I came up with was to have 3 key shards with a threshold of 2 to unlock. To have any benefit here, you obviously need to store the three shards in different locations, which is exactly what I'm doing. I've got one that is GPG encrypted on a thumb drive in a bank safety deposit box, I've got one GPG encrypted on my laptop, and I've got one GPG encrypted on my phone. As a note, I run full disk encryption on my laptop, fully encrypt my phone, etc. and I don't share passwords between devices. If someone wanted to compromise my unseal keys they'd have to first gain access to my laptop AND phone, plus have the password to decrypt the keys. There are some obvious drawbacks to this method. If I were traveling and my Vault was sealed, maybe I only took my phone with me but not a laptop, and suddenly I need a password, I would be out of luck. I figure in a case like this I could always reset the password at the time and fix the problem later, so I'm okay with it as a solution, and I feel it's the most secure way to handle this.


All Vault authentication ultimately results in a user being given a token (whether they know it or not) that is used to interact with a given instance of Vault. Userpass is probably the most user-friendly and easy to setup. It's, as the name might imply, simple username passwords to obtain a token and thus login to the web UI or using the vault CLI. I think it's perfectly suitable for personal use, so long as you are rotating your main password regularly. Also, be sure to restrict each user you create to only the policies it needs. This is a great way to limit the scope of a breach were you to experience one! That's mostly all I've got to say here. You can also distribute a token for yourself directly that doesn't really expire if you prefer it to having a username/password, but that seems much less flexible to me.

Token Restrictions, combined with good policy

I am going to be primarily focusing on the "userpass" auth method here, as it's what I am using and what I feel most people would be using for a personal Vault instance. In the configuration options for the userpass auth, looking at the web UI here, there is an option to restrict a user's token to specific cidr blocks. This means if accessing Vault from an IP outside of the provided range(s), the token will not be given access. In my case, my Vault instance is locked down to my VPN-only, so my "daily driver" account, named 'jonathan' here, has cidr-restrictions like so:


This means even if somehow someone were to access the service anywhere other than my VPN, there is now an additional layer of security saying that tokens generated for user 'jonathan' wouldn't be usable.

Regardless of how you're generating tokens for yourself to login, you can use cidr restrictions if using a VPN setup like mine to restrict use.

Another note, for each user you create using userpass, you choose which policies get attached. The account I intend to use daily will only have access to passwords I'll need regularly (banking, systems I access, whatever). It won't have access, however, to things like my PKI for my VPN server. Why? Well, on a regular basis I'm not going to need access to that, so in the event my most commonly used account is compromised, at least the damage is minimized.

Oh, one last note - you can set token TTLs. Use shorter TTLs wherever you can. Realistically you're going to login looking for a single password at a time with your "daily driver" account. My tokens issued via userpass expire after 5 minutes, forcing me to reauthenticate often. This means if a single token were compromised, it'd be a 5 minute ordeal. 5 minutes is plenty of time to login to the web UI, navigate to the password I need at a point in time, and copy it.

← Return to previous page