The problem is also discussed here:
opened 07:48PM - 15 Jan 19 UTC
enhancement
core/seal
community-sentiment
**Is your feature request related to a problem? Please describe.**
We need to… plan for a scenario where someone accidentally deletes a KMS key, or KMS itself is inaccessible in a region. I've tried the following as a simple test:
* Create consul and vault clusters in two regions, region1 and region2
* Enable Auto Unseal using `awskms` with a KMS key in region1
* Take snapshots of consul from region1
* Stop clusters in region1 and disable/delete KMS key in region1
* Restore consul snapshot from region1 in region2
* Attempt to start Vault
This fails because the KMS key is disabled/deleted/inaccessible from the new cluster.
Essentially I want the ability to take a consul snapshot and restore it on a server that does not have access to the KMS key used by the vault cluster with auto-unseal using awskms enabled.
**Describe the solution you'd like**
I think supporting multiple `seal` blocks or kms ids in the `awskms` seal block may be the simplest solution. This could look something like this:
```
seal "awskms" {
region = "us-east-1"
kms_key_ids = [
"region1/19ec80b0-dfdd-4d97-8164-c6examplekey",
"region2/12e4e120-dfdd-4d97-8164-c6examplekey2"
]
}
```
In my example, I would specify KMS keys from two (or more) regions. Vault would then encrypt the master key against every KMS key in the list.
I would then be able to take a consul snapshot in region1, create a consul/vault cluster in region2, restore the snapshot, bring up the vault cluster and have it auto unseal as normal.
If supporting multiple kms keys wouldn't work for some reason, then I think allowing the original unseal keys (recovery keys) to unseal a vault cluster would also be a reasonable solution.
**Describe alternatives you've considered**
- Enterprise DR would essentially solve the issue, but that is a long-term solution and not available when only using the OSS version of Vault.
- Originally I was under the impression that the "recovery keys" could be used to unseal a vault cluster that had auto unseal enabled. This isn't the case, and makes their name seem misleading unless they serve a purpose other than generating root tokens or removing auto unseal (while auto unseal is still enabled and working.)
- Another option considered was to import custom key material into a new KMS key. Because the old encrypted data references the original KMS key id, this doesn't work when that key no longer exists.
**Explain any additional use-cases**
Without this feature, it is impossible afaict to properly backup a Vault cluster with Auto Unseal enabled. Even with Enterprise DR and replication, you wouldn't have a true backup as you can't back up the KMS keys.
Please let me know if I am misunderstanding something or if there is an alternative solution.
Thanks!
We need to plan for a scenario where someone accidentally deletes a KMS key, or KMS itself is inaccessible in a region.
Another option considered was to import custom key material into a new KMS key. Because the old encrypted data references the original KMS key id, this doesn’t work when that key no longer exists.
As I understand, the key ID is randomly generated.
2 Likes