Why can't I change the unseal/recovery key after migration to transit auto-unseal?

Vault
1

I have successfully migrated the seal type for a Vault cluster from shamir to transit. During this process, Vault did not create recovery keys. Running the rekey procedure (vault operator rekey) yields an empty list of keys (tried CLI and REST API). Amazingly, I can repeat this procedure forever, and Vault happily accepts the original unseal key from its initial setup. So, it looks like I’m unable to change or replace the unseal keys, meaning anyone who knows them can create new root tokens forever. The documentation does not explain this behavior.

Looks like this issue affects only migrated seal types.

Can somebody with insights please explain what’s going on behind the scenes?

By the way, the CLI outputs “nothing” (no new keys) and should probably print out something more helpful if Vault cannot rekey:

$ vault operator rekey
Rekey operation nonce: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Unseal Key (will be hidden):

Operation nonce: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Vault unseal keys rekeyed with 1 key shares and a key threshold of 1. Please
securely distribute the key shares printed above. When Vault is re-sealed,
restarted, or stopped, you must supply at least 1 of these keys to unseal it
before it can start servicing requests.

Thanks for your help.

2

When you use an auto-unseal service such as transit, or a KMS, your unseal keys are handled by the external system - in this case transit. With Shamir, its manual, which is why it gives you keys.

Rekey on its own produces the unseal keys, for your recovery keys you want to use the -target parameter.

More details in: