Using autounseal in helm deployment

Vault
,
1

Is it possible to have 2 Vault instances auto-unseal each other?

Current Setup

I currently have two HashiCorp Vault instances deployed in separate locations, both being used in production. I’d like to configure them to auto-unseal each other, so that if one goes down, the other will still be available to unseal it when it comes back online.

Questions

  1. Mutual Auto-Unsealing: Is it possible/advisable to have two Vault instances auto-unseal each other? Is this considered good practice from a security and reliability standpoint?

  2. Migration Path: Most documentation (like the Transit Auto-Unseal tutorial) describes setting up auto-unseal on a clean Vault. My Vault instances are already in production with existing data. What’s the migration path to implement auto-unseal without losing data? I can accept some downtime, but need to preserve all secrets.

  3. Manual Unsealing Option: If auto-unseal is enabled, can I still manually unseal the vault if necessary? Is there a fallback mechanism?

  4. Helm Configuration: When using Helm to deploy Vault, how do I configure the auto-unseal feature? Is it just a matter of creating a ConfigMap somewhere, or do I need to include specific configurations in my values for the chart?

Additional Context

I understand this is a multi-part question, but I’d really appreciate insights from anyone with experience implementing a similar setup. Thanks in advance for any guidance!

2

Hey! I will try to answer your questions.

Mutual Auto-Unsealing
I would not recommend this. In the rare circumstance of both clusters going offline they will never be able to unseal again. The recovery keys generated from the initialization process, when using auto-unseal, are not sufficient for unsealing Vault.

If you already have two completely separate Vault clusters using Shamir keys, I would recommend either using Cloud KMS keys for auto unseal or spinning up a third Vault cluster that will be used only for auto-unsealing (Transit) purposes. If you are on Vault enterprise, there is also the option to use an HSM.

Migration Path
Vault supports a seal migration path, refer to the documentation. Note that you cannot perform the seal migration process without downtime. Also, you should make sure to create a backup before you start the seal migration process, in case something goes wrong.

Manual Unsealing Option
If you are using auto-unseal (Transit or Cloud KMS), you are given recovery keys instead of unseal keys during the initialization process. As previously stated, these recovery keys are not sufficient to unseal Vault.

If you have connectivity problems (your Vault transit cluster goes offline, or a cloud outage impacting KMS keys) then new instances of Vault won’t be able to unseal until connectivity is restored. If the Transit or Cloud KMS key is deleted, then Vault will not be able to unseal.

If you are on Vault Enterprise, I would look at Seal high availability, allowing you to configure more than one auto seal mechanism such that Vault can tolerate the temporary loss of a seal service or device.

Helm Configuration
If you are using Helm, you can specify a custom Vault config in the Helm chart values.
This highlighted section is where the config for a HA Raft cluster, you can override this default config with one including your specific seal stanza.

3

thanks for the answer, so if I understand correctly you can chose between auto unseal and manual unseal they cannot be both active.

and to the same train of thought what are the recovery keys used for if it’s not to unseal

4

That is correct, even with Vault Enterprise’s Seal High Availability, you cannot mix Shamir with Auto-Unseal on a single cluster.

For recovery keys, there are a few operations where you need a quorum of operators. These operators will present their recovery key. One example of this is generating a new root token.