support k/v v2 api

[nferch]

v2 of the k/v backend in Vault has a slightly different response format:

{
  "data": {
    "data": {
        "foo": "bar"
    },
    "metadata": {
      "created_time": "2018-03-22T02:24:06.945319214Z",
      "deletion_time": "",
      "destroyed": false,
      "version": 1
    }
  },
}

https://www.vaultproject.io/api/secret/kv/kv-v2.html

So try and detect these responses and parse accordingly:

[petems]

The urgency for this has bumped a bit now 1.0.0 uses v2 by default, let me try this and I'll see if I can merge later

[nferch]

Curious whether there's precedence or recommendation to determine the version of the API being queried, this seems a bit brittle and magical.

[petems]

Luckily I have direct access to the engineers, so I can find out the best way of doign this 😄

[petems]

Ok, unfortunately, it's not this easy 😢

KV v1 the API is:

https://127.0.0.1:8200/v1/secret/my-secret

https://www.vaultproject.io/api/secret/kv/kv-v1.html

In KV v2, the API is:

https://127.0.0.1:8200/v1/secret/data/my-secret

https://www.vaultproject.io/api/secret/kv/kv-v2.html

So we cant check for the metadata field, as we'd have to change the path dynamically depending on if the kv endpoint is 1 or 2. Luckily: there is a way of doing this: check the mount given's option setting (https://www.vaultproject.io/api/system/mounts.html#version)

Unfortunatly, this isn't an option in the Vault gem yet. Opened an issue for that.

[nferch]

My assumption was that the v1 response would never have the metadata field so you could assume if the key existed the endpoint was v2.

Unsure what the tradeoff would be for querying the mounts endpoint and save that result somewhere, but will defer to those more familiar with the code.

[petems]

No worries! 😄

Closing, but adding to #23 for further investigation