The information contained in this article has been verified as up-to-date on the date of the original publication of the article. HashiCorp endeavors to keep this information up-to-date and correct, but it makes no representations or warranties of any kind, express or implied, about the ongoing completeness, accuracy, reliability, or suitability of the information provided.
All information contained in this article is for general information purposes only. Any reliance you place on such information as it applies to your use of your HashiCorp product is therefore strictly at your own risk.
Introduction
It may become necessary that if you are running multiple vault clusters to support a transit unseal autounseal architecture that you may want to move an existing transit unseal key to a new vault cluster. While the recommended approach would still be to migrate seals from transit auto unseal to shamir and back again to a new seal on the new cluster, you could also just move the key it's self.
Procedure
- Enable the exiting key to be able to be backed up
vault write -f transit/keys/autounseal/config allow_plaintext_backup=true
- Backup the key to a file
curl --header "X-Vault-Token:<vault token>" https://<vault addr>:8200/v1/transit/backup/<current key name> -H "Accept: application/json" | jq .data > payload.json
- Restore the backup to a new key (note: the key must not presently exit i.e. cant be posted to an existing key to overwrite)
curl --request POST --header "X-Vault-Token:<vault token>" --data @payload.json https://<new vault addr>:8200/v1/transit/restore/<new key name>
- Update the vault server configuration vault.hcl to point to the new key with a token that has appropriate permissions to access it as per Configure Auto-unseal Key Provider then restart the vault node to point to the new seal.
seal "transit" {
token = "<new token>"
address = "https://<vault transit server api address>:8200"
disable_renewal = "false"
key_name = "<new key name>"
mount_path = "transit/"
tls_skip_verify = "true"
}