In this blog edition, we’ll look at what Vault’s seal status means, different ways to unseal vault servers and when we can expect to find vault in a sealed state.

Sealing is Vault protective mechanism that prevents you secrets from being accessible if the Vault server is ever compromised in any way. When you first deploy a Vault server, it is in a sealed state, which means, there aren’t many actions you can perform on the server. In fact, the only actions you can perform on Vault whilst in a sealed state are:

  1. Check the Vault status
  2. Initialise and unseal the Vault.

When a Vault server is first deployed, the first thing you will have to do to it is initialise it. The initialisation process generates a couple of things which are crucial to the management of the server.

Firstly, it will generate five unseal keys. As the name suggests, these keys can be used to unseal the Vault server. By default, you need any three of the five unseal keys to unseal the server.

The second thing that the initialisation process does for us is generate a root token for us to use to log in to the server and perform initial configuration tasks. The root token is similar to the root user on Linux systems in that, it has unrestricted access to everything. This token should be handled with care and should eventually be deleted once the server has been properly configured. There are mechanisms built into to Vault that allow operators to re-generate new root tokens if they have the correct permissions.

Going back to unsealing the Vault server, the unseal keys generated by the init process are equally as sensitive as the root token and too, need to be handled with care. The keys should never be stored together as that defeats the object. Instead, they should be carefully distributed out to five trusted operators to store securely.

In the event of a server restart, the Vault server will need to be unsealed, which requires three out of the 5 operators to enter their unseal keys in order to restore Vault services to normal. This is fine when the restart happens during the working day; however, it’s not so cool if the server restart occurs at 3am on a Sunday morning. This scenario would mean having to wake up engineers in the middle of the night for them to enter their unseal keys.

When Architecting your Vault deployment, there is a feature you can include in your design that solves this problem. This feature is Vault auto-unseal. This feature uses a trusted cloud Key Management System (KMS) to automatically unseal the server when this feature is configured. This is done by the KMS decrypting and encrypting the Vault server’s master key.

Vault supports auto-unsealing using KMS offerings from the four main cloud providers (Azure, AWS, GCP and Alicloud). In addition to these options, there is also an Enterprise only option of PKCS11 with HSM auto-unseal mechanism as well as the in-built Transit mechanism that you can take advantage of.

Which auto-unseal mechanism should I choose?

Much like many of the other architectural decisions that we have discussed over this series of blogs, the answer to this question will differ from one organisation to the next and will depend on one main factor, which is, what cloud strategy if any is in place?

Organisations with a cloud strategy will more than likely choose an auto-unseal mechanism with their main cloud provider; however, organisations who pay for a Vault Enterprise license may prefer to take advantage of the PKCS11 options, which after all is one of the features they are paying for. Organisations who are completely on-premise and using open source Vault are better suited to the Vault Transit mechanism. Whichever option you choose when enabling auto-unsealing, it should reflect the technology roadmap of the organisation.