Recovering from auto-unseal KMS key deletion using Recovery Keys

Vault
1

I am currently documenting a migration from a Shamir-sealed OSS Vault cluster to Google KMS-based Auto-Unseal. I want to verify a specific “worst-case” disaster recovery scenario which seems like it shouldn’t work based on Vault documentation, but

The Scenario:

  1. We migrate from Shamir to Google KMS auto-unseal.

  2. Our original Shamir shards become the Recovery Keys.

  3. We rotate these Recovery Keys (-target=recovery) and store the new quorum safely.

  4. The KMS key undergoes several version rotations over time.

  5. The Disaster: The Google KMS key (all versions) is accidentally deleted.

Our Proposed Recovery Procedure: Since a standard auto-unseal will now fail, our plan is:

  1. Provision a brand-new KMS key in GCP.

  2. Restore the latest Vault storage snapshot (Consul) to a new instance.

  3. Update vault.hcl to point to the new KMS Key ID.

  4. Start the Vault server. It will initially be in a sealed state and fail to auto-unseal because the barrier is wrapped with the deleted key.

  5. Run vault operator unseal -migrate and provide the quorum of Recovery Keys (the ones generated in step 3).

My Questions:

  • Even though the KMS key is deleted, will the unseal -migrate flag allow the Recovery Keys to reconstruct the Master Key in memory to authorize a re-wrap to the new KMS key?

  • Does the fact that the KMS key rotated versions between the time the Recovery Keys were generated and the time of deletion affect the ability of those Recovery Keys to decrypt the barrier?

  • Is this an officially supported “Break-Glass” path for total loss of a Cloud KMS provider?

I’ve seen the general warnings in the documentation about deleted seal keys rendering a Vault cluster “unrecoverable” (which is why we’re also documenting methods for securing those keys), but I want to confirm if the -migrate workflow provides an exception for restoring into a new cluster with recovery keys.

Thanks in advance for the help!