search

hashicorp / vault

A tool for secrets management, encryption as a service, and privileged access management
https://www.vaultproject.io/
Other
30.87k stars 4.18k forks source link

Support copying non-exportable secrets to new names #6747

Open sgrimm-sg opened 5 years ago

sgrimm-sg commented 5 years ago

When application requirements change, sometimes the initial decisions about how to name secrets in Vault are no longer appropriate, but at the moment, Vault secret names are set in stone the moment they're created.

The closing comment on https://github.com/hashicorp/vault/issues/4525 suggests dumping out the existing values and creating new keys with the same values, but that only works when values are accessible. If you want to rename a Vault-generated certificate or a transit key that you didn't set as exportable at creation time, as far as I can tell there is no way to follow that suggestion.

A "rename" operation would be helpful, but even more helpful would be the ability to copy a value to a new name (under the same secrets engine) without exposing its value to the client. That way, applications could migrate to a new naming convention without needing to cut over at exactly the same instant the rename happens: the new name could become active and then the old one deleted only after the applications have started using the new one.

The alternative is to always mark all Vault-generated secrets as exportable just in case they might need to be renamed at some point in the future.

anitakrueger commented 3 years ago

Is there any progress on this? Unfortunately we had to move our Vault structure to a new naming convention and I am now faced with having to export all the secrets and recreating the exact same ones under a new folder structure, but in the same secrets engine. Would be so much easier if there was a "rename" feature.

f4z3r commented 1 year ago

I am now facing a similar issue with transit keys. How would you image this looks like? I could spare some time in the coming weeks to implement it. I am however unsure what a nice approach would be. Off the top of my head I can only think of having an endpoint such as:

POST transit/move/:name

Which would take a data field to (or the like) for the new name. That way the path structure is similar to the backup/restore/export/import/etc actions.

Another option would be to somehow integrate it into a configuration update via the standard transit/keys/:name/config, but I feel this might cause confusion and might break permissions that some people have set up in their Vaults (e.g. if I can update the config of a key, I can move it to some path where I might have more elevated priviledges).