Remove the hard-coded "value" key used in get/set
Closed this issue · 4 comments
The kv engine of Vault stores key/value dicts but the current version of vault-cli forces a hard-coded key named value. This way the user thinks that there is a "single value" associated with a path (instead of a dict).
Unfortunately this is a limitation for some use-cases (use of other engines, work with values set with another tool than vault-cli, ...).
Here is a proposal for dropping this hard-coded key and working with k/v mappings instead.
#
# SET
#
# overwrite the whole mapping
vault set path/to/creds key1=val1 key2=val2
# Using a file (json/yaml)
vault set path/to/creds --file=/path/to/file.yml
echo '{"key1":"val1", "key2": "val2"}' | vault set path/to/creds --file=-
# updating a mapping (could be the default ?!)
vault set --update path/to/creds key3=val3
# reading a (string) value from stdin
vault set path/to/creds key1=val1 key2=- < /path/to/val2
# if you have multiple files to read then you'll have to run the command multiple times with --update
#
# GET
#
vault get path/to/creds key1 # reads the value of key1
vault get path/to/creds # no key specified, returns a mapping in json
#
# DELETE
#
vault delete path/to/creds # delete the mapping
vault delete path/to/creds key1 # only delete key1
How does it work with the currently stored structure ?
How does it work with the currently stored structure ?
If you use the same commands, then you will get a value: xxx mapping instead of just xxx
I vote for update being the defaut, and —clear otherwise.
I also wonder if we should offer a compatibility flag, even just for a single version, but it’s probably be complicated to code.