Browser CLI commands: unable to write to KV v2

Vault
1

Hi,

I’m trying to use the embedded browser CLI to write to a KV v2 engine and I’m not sure if I’m doing it right, but it is not working. I simple started a dev server (version 1.6.3), logged in with root token and did the steps below:

1st attempt:

$ write secret/test foo=bar
Error writing to: secret/test.
URL: /v1/secret/test
Code: 404

Ok, KV v2 API states clearly that the URL to create secrets must contain “data” after the name of the secret engine.

2nd attempt:

$ write secret/data/test foo=bar
Error writing to: secret/data/test.
URL: /v1/secret/data/test
Code: 400
Errors:
  no data provided

Now it’s odd. I have provided “foo=bar” as data.

3rd attempt

$ write secret/data/test data='{"foo":"bar"}'
Error writing to: secret/data/test.
URL: /v1/secret/data/test
Code: 400
Errors:
  error converting input {"foo":"bar"} for field "data": '' expected a map, got 'string'

Hmm, so when I declare explicitly the field “data”, it recognizes it, but complains it’s not a map.

I tried a lot of different formats for the field “data” without success.

$ write secret/data/test data=foo:bar
$ write secret/data/test data=foo=bar
$ write secret/data/test data.foo=bar
$ write secret/data/test data[foo]=bar
$ write secret/data/test data["foo"]=bar

4th attempt (“hacking” into this thing)

So I decided open the hood and see how the UI was making the API requests, and eventually stumbled on this function:

write: function(e, t, n) {
  return this.ajax("write", r(e), {
    data: t,
    wrapTTL: n
  })
}

Debugging I could see that:

e = "secret/data/test", t = {foo: "bar"}, n = undefined

And as this variable “t” is being passed directly to ajax lib, without being enclosed in a object with “data” attribute, I decided to help with a little “hack”:

$ write secret/data/test foo=bar

Breakpoint at function above and run at developer tools’ console:

t = { data: t }

Key           Value                         
created_time  2021-02-26T18:43:44.445292403Z
deletion_time                               
destroyed     false                         
version       1

And it worked!

The questions

  1. Am I using it wrong or is it a bug?
  2. Where are the docs on those commands?
  3. Are they using the same syntax as CLI, but with fewer options?

Bonus

I thought that maybe this command is not prepared to work with KV v2 and decided to try it with KV v1. Created a secret engine KV v1 called “kv1” and it works perfectly. Maybe it was not evolved to work with KV v2 yet?

$ write kv1/test foo=bar
Success! Data written to: kv1/test

Thanks,

2

Commendation on all the research here :slight_smile: but…
I don’t think there’s an equiv in there for:
$ vault kv put kv2/yourSecret foo=bar

I’d just use the real CLI and not the web one. Might be worth putting an issue in? Unsure the roadmap of the web CLI.

3

Are there any known plans on the roadmap for the web cli to provide the functionality to allow for writing KV2 secrets as well as the patch capability?

This issue still exists on the web cli in v1.9.1 for writing kv2 secrets.

4

Are there any known plans on the roadmap for the web cli to provide the functionality to allow for writing KV2 secrets as well as the patch capability?

I doubt this would be made any easier, however it is possible.
The API endpoint for the KV secret engine to create a new secret exists but is rather hard to interpret into your shell. Patch also exists and is also hard to use.
The kv subcommand has been made to make this easier.

5

Thanks for the response. We are aware of the API capabilities, however we were hoping to provide the Web-UI to Product Owners, as an easy way to allow them to populate KV2 secrets, without having to engineer another method. While this works fine, we have a security requirement to remove READ permission on secret paths for HUMANS, which plays havoc with the normal Web-UI functionality for KV2 versioned secrets. Naturally the Web-cli was the next logical option - which unfortunately does not provide the functionality either.

6

When talking about your security requirement: does this count for any data including metadata? Or is the requirement about reading secret data?

7

It is purely disabling the ability for a human to read the secrets via Web-UI, but still allow the functionality for them to add secrets - in the PATCH manner. Removing read results in the secret being overwritten and a new secret being created. Essentially KV2 behaving like KV1.

8

Here where I work one of the uses of Vault is to store some personal secrets that are used in CI pipelines. Basically access tokens for some third-party tools for source-code scanning, image repositories and Git repositories. So the way I intended to use the Web CLI was as a single-operation way for the users to create their own secret, which seems easier to follow and to put in a documentation than the regular way of creating secrets in the UI. But I think that it would also be nice to allow users to check if their secrets are correct in Web CLI.

But I’m telling this just to add information for the discussion. I agree that security concerns are more important.

Ps.: The main reason I’m considering users using the Web CLI is this issue below. I have hundreds of users and sometimes they have difficulty navigating through Vault UI.

10

I use “vault kv pach secret/test foo=bar”, then it successfully write.
the vault cli is very very difficult to use and understand, the online guide is totally shit, so and the help doc and the return message.