Check what version of kv secret

Vault
1

I’ve been trying to understand what version is created by default when enabling kv secret, and while it seems to be version 1 (I’ve tested it by using the version-1 paths), the description are hardly clear.

In this case I’ve enabled a secret without specifying the version, but the version is not specified unfortunately when I look it up:

root@vault-0:~# vault read /sys/mounts/normal
Key                        Value
---                        -----
[...]
options                    <nil>
plugin_version             n/a
running_plugin_version     v0.13.0+builtin
running_sha256             n/a
seal_wrap                  false
type                       kv
[...]

Similarly I get:

root@vault-0:~# vault read -format=json /sys/mounts/normal | jq -r '.data.options.version'
null

When specifying the option, I get by options map[version:2] or map[version:1]. Any ideas what’s going on and why vaults doesn’t show the version?

2

Absence of a version means the same as version 1.

I agree this is an unfortunate design choice, and not having multiple ways to represent the same thing would be better.

1 Like
3

Thank you!
It’s not clear to me though, I’m guessing hashicorp recommends using version 2? And version 1 will become obsolete at some point?

Is there anywhere I can read about why allow_parameters and such have become obsolete in version 2?

4

I think this is unlikely. There would be very minimal benefit indeed in dropping support for KV v1, whereas the amount of grief caused to customers would be large.

It’s because allowed_parameters is a generic mechanism for filtering which JSON keys are allowed in the top-level of a request to Vault, but KV v2 changes the format of the request to place all the user data under a top-level data key - so the user data is now in a more deeply nested part of the JSON than what the allowed_parameters mechanism is testing.

1 Like
5

So if I started out with vault, do you think I should use one or another? Or it simply depends on my requirements and I could even use both?

6

It depends a lot on your requirements.

My organization made a choice to mostly use KV v2, and I think it was the wrong choice, because so many of our users get tripped up by the need to insert /data/, /metadata/, etc. in URLs in various places.

KV v1:

  • Simple, few surprises, easy to educate users about

KV v2:

  • Versioning support - needing/wanting multiple versions of secrets stored, and to be able to look back at old versions, is the main reason to use v2
  • Encrypts the keys (v1 doesn’t encrypt the keys, someone with access to the raw storage can read them)
  • Supports server-side PATCH
  • Supports the /subkeys/ operation to peek at JSON subkeys inside a value, without disclosing the values
1 Like
7

Thank you! This is a really nice summary, this will definitely help me :slight_smile: