Vault: Add ability to move or rename a folder

[rptxcosmo]

Currently we cannot move or rename a folder containing secrets.

[jefferai]

There are no plans to implement this.

[alexandernst]

@jefferai Are you willing to accept a PR implementing such a feature?

[jefferai]

No. Unlike on a filesystem, we can't guarantee atomicity for renames. So there is no benefit to doing this server side and simply added complexity over doing it client side.

[alexandernst]

There is no need of atomicity. I'd approach the problem by simply recursively iterating over all the secrets inside the folder that is to be renamed and copying them to the folder with the new name. Once the operation is done, delete the old folder.

It's a very simple operation and it will allow achieving something that imho should be already provided by default in Vault.

[jefferai]

That's my point -- given that you can only perform this by doing exactly the algorithm you mentioned, there's no reason to make it a server-side operation instead of a client-side operation, and in fact for auditing reasons it's actually nicer to ensure that each move is audited independently.

[xbglowx]

I created a new client binary to help with this: https://github.com/xbglowx/vault-kv-mv

[andrewsav-datacom]

@jefferai is there a reason why this cannot be supported by Vault UI?

[zhenyulin]

I'm using the command line as the follows to rename a secret directory, which can be created as a Makefile command to take variables:

vault read {$CURRENT_SECRET_PATH_PATTERN} -format=json | jq '.data' | vault write {TARGET_SECRET_PATH_PATTERN} -

[kirelagin]

Moving/renaming a single secret seems to be useful though, doesn’t it? Because this can be done without reading the secret (i.e. sending it to the client), which is a more secure approach.

[kirelagin]

And then renaming a folder turns into a loop that moves each secret independently. The advantage is that secrets never leave the server, compared to the jq approach, in which _all_ moved secrets leave the server and get non-trivially processed on the client side.

[gmeister-ticketline]

3 years on and you haven't modernised to include a move / rename feature?
It is clearly safer and far more secure to do an internal loop copy operation than a client read - client change - client write operation. This is especially true for organisations with large secret stores with heavily secured servers. It negates the point of having heavily secured servers if you must do CRUD operations on secret folders on client side.

[gmeister-ticketline]

Additionally, from a business perspective, it's these kinds of inflexible design decisions by framework providers that make organisations decide to move frameworks. Usually data migration (including secrets) means updating their systems to something new. There's also no penalty to move to a new provider if you're going to have to do the work again.
The same can be said for design decisions on Terraform, but that's a different conversation.