Streamline Vault Operations: A Guide to Mastering Auto Unseal

Unsealing Vault after a server restart is one of those tasks that, while essential, can quickly become cumbersome—especially when you’re managing multiple Vault nodes or clusters. Enter Auto Unseal, a lifesaver in production environments, as it automates the process of securely unsealing Vault without requiring manual intervention.

In this blog post, we’ll explain how Vault’s Auto Unseal works, discuss implementation options, and walk through practical steps for configuring it using cloud-based Key Management Services (KMS) and Vault’s Transit Secret Engine**.**

By the end, you’ll not only understand how Auto Unseal works, but you’ll also be ready to configure it in your environment.

What is Auto Unseal?

In a standard Vault setup, unsealing requires manually entering a set of unseal keys to decrypt the master key and bring the Vault server online. These keys are distributed to several people so no one has all the keys to the castle, i.e. your vault secrets.

This is a great security measure, but it doesn’t scale well when you run multiple nodes, need high availability in production environments, and need key holders online to bring Vault up.

In this setup, we have an encryption key to encrypt our data; to protect that encryption key, we have a master key that encrypts the data key. This master key is then split into different key shards using the shamir. This allows the master key to be re-created from the minimum threshold of Shamir key shards, which is set when you unseal your Vault server for the first time.

Auto Unseal automates this process by offloading the secure storage and retrieval of the master key to a trusted third-party service, such as a cloud KMS or another Vault cluster. This allows Vault to automatically unseal itself after a restart or outage without manual intervention, which is crucial for maintaining uptime and reducing operational overhead.

Now our master key is encrypted with the cloud-based key and stored within the vault storage. Nothing is stored in the cloud-based service, it is purely used for encryption and decryption of the master key when vault starts up.

Auto Unseal Options

There are two primary ways to implement Auto Unseal:

Cloud Key Management Services (KMS): Many organisations use a cloud provider’s KMS to store and retrieve the unseal key. This method integrates with:

• AWS KMS
• Azure Key Vault
• Google Cloud KMS

Vault Transit Secret Engine: You can also use another Vault cluster to securely store the unseal keys. This method is ideal if you want to keep all key management within the Vault ecosystem, leveraging a primary Vault cluster to unseal other clusters.

Configuring Auto Unseal

Let’s walk through how to configure Auto Unseal with both AWS KMS and Vault Transit. The steps are similar for Azure and Google Cloud, with slight differences in the KMS configuration.

Auto Unseal with AWS KMS

Using AWS KMS to unseal Vault is one of the most popular methods, thanks to the robust security and easy integration that KMS offers.

Create a KMS Key in AWS

First, create a KMS key that Vault will use for auto unseal. Note the KMS Key ID and ARN; you’ll need them in Vault’s configuration.

Update Vault Configuration

Once the KMS key is ready, update Vault’s configuration file (vault.hcl) with the necessary KMS details.

This is done in the seal stanza:

seal "awskms" {
    region     = "ap-southeast-2"
    kms_key_id = "arn:aws:kms:ap-southeast-2:123456789012:key/EXAMPLE"
}

This tells Vault to use the specified KMS key for unsealing. Replace kms_key_id with the ARN of your KMS key and region with the appropriate AWS region.

Start Vault and Verify Auto Unseal

Restart Vault to apply the new configuration. If everything is set up correctly, Vault should automatically unseal itself using the KMS key without any manual intervention.

To verify that Vault has auto-unsealed, use the vault status command:

vault status

Key                      Value
---                      -----
Recovery Seal Type       awskms
Initialized              false
Sealed                   true
Total Recovery Shares    0
Threshold                0
Unseal Progress          0/0
Unseal Nonce             n/a
Version                  1.12.2
Build Date               2022-11-23T12:53:46Z
Storage Type             file
HA Enabled               false

You’re good to go if the output shows that the Vault is unsealed!

Implement Auto Unseal Using Vault Transit Secret Engine

For those who want to keep everything within the Vault ecosystem, using Vault’s Transit Secret Engine for auto unseal is a solid choice. This setup requires a primary Vault cluster that will act as the KMS for unsealing secondary Vault nodes.

Set Up a Primary Vault Cluster

First, you need a primary Vault cluster where you’ll enable the Transit Secret Engine.

Enable the transit engine using the following command

vault secrets enable transit

Create a transit key that will be used to encrypt and decrypt the unseal keys:
shell

vault write -f transit/keys/unseal-key

This primary cluster will now handle the unseal process for the secondary Vault nodes.

Update the Secondary Vault Configuration

Next, update the configuration of your secondary Vault cluster to use the primary cluster for auto unseal. Add the following seal stanza to the secondary cluster’s configuration:

seal "transit" {
address = "https://<primary-vault-address>:8200"
token   = "s.XYZ123..."  # Token with permission to access the transit engine
disable_renewal = "false"
key_name = "unseal-key"
mount_path = "transit/"
}

Ensure the address points to the primary Vault’s API endpoint, and that the token has sufficient permissions to interact with the transit secret engine.

Start Vault and Verify Auto Unseal

After updating the configuration, restart the secondary Vault server. The secondary instance should now auto-unseal using the transit engine from the primary cluster.

Check the unseal status with:

vault status

If the secondary Vault node is unsealed, the setup is complete!

3. Compare Auto Unseal Methods

Each auto unseal method has its pros and cons. Here’s a quick breakdown:

When evaluating auto unseal methods, consider the following:

• Security: All methods provide robust encryption, but it makes sense to consolidate if you’re already using a KMS for other services.
• Cost: A cloud KMS may incur extra costs, while the transit engine uses existing Vault infrastructure.
• Complexity: KMS integration is relatively straightforward, while the transit engine introduces additional management for a primary Vault cluster.

Final Thoughts

Auto unseal is essential for production environments where you need to reduce operational overhead and ensure high availability. Whether you’re using AWS KMS or Vault Transit, automating the unseal process ensures that Vault is always available and reduces the need for manual intervention during restarts or failovers.

By practicing the exercises above, you’ll gain hands-on experience configuring auto unseal and be well-equipped to decide which method works best for your production needs.

Stay tuned for more posts as we continue to explore advanced Vault features and best practices!

Hope this helps someone else!