K/V Versioning

[nickcarenza]

This package stopped working on latest vault k/v store and I think it has something to do with the new versioning feature in Vault.

https://github.com/hashicorp/vault/issues/4281

[kr1sp1n]

@nickcarenza Will have a look at it asap. Thanks for reporting the issue 🙏

[ak1394]

It should be possible to force Vault to use KV Version 1 backend instead of KV Version 2 which looks like a default for the new installs and the dev mode. Reverting to the old backend should solve the issue.

However, it would be nice to get support for the new KV backend in the future.

[shovelend]

@kr1sp1n it would be amazing to have the feature. We're looking forward to use KV Secrets Engine - V2 and we couldn't find a decent library apart from yours. Do you think it will be implemented soon?

[kr1sp1n]

@shovelend We are working on version 1.0.0 atm. That's why there is a slow progress with all the other feature requests. But I think the KV Secrets Engine V2 could be implemented easily and released as 0.9.0 in the meantime. Will work on this next week.

[v6]

// , You can create multiple KV secrets backends in Vault, and have some of them set to v1, with others set to v2. They can coexist, but the paths will be different.

You can set up HashiCorp Vault with a way to support the legacy interface for backwards compatibility without affecting other use cases.

Instead of "${VAULT_ADDR}/v1/secret..." your paths would use "${VAULT_ADDR}/v1/kv1..." or some such thing.

I would ask yourself whether you need the versioning and Check-and-Set (CAS) features, though, first.

Even if you don't need them right now, it might be helpful to have them in the back pocket for later.

[v6]

// , Here's a guide on how to do the operation I mentioned above:

https://www.vaultproject.io/intro/getting-started/secrets-engines.html#enable-a-secrets-engine

[tmackness]

Just notice this was to do with KV v2. Couldn't figure out why it wasn't working. Appreciate the work around.

[petermyers]

As we approach the end of 2019, i was wondering if there was any update on this?

[stevenaldinger]

for what it's worth, you can still read values with this lib if you add /data/ between the secret engine and the secret.

// not sure if apiVersion does anything, didn't look
const vault = require('node-vault')({ endpoint: "your-endpoint.whatever", token: "s.your-token", apiVersion: "v2" })

vault.read(`secret-engine/data/my/secret/here`)
  .then(({ data }) => {
    console.log(data)
  }

I wasn't able to get writing to work the same way but just threw the vault CLI commands into a bash script for myself based on that output for my very specific use case.

[v6]

Yeah I currently do not recommend using this library or the ruby library because of this type of thing.

[owenfarrell]

Looks like you're running in to the same issue as #148.

Per my comment...

I had to solve the same problem for my VisualStudio Code extension (which uses this library). My solution was to simply adapt the node-vault client as necessary based on the metadata associated with engine mount points.

Example Implementation

[aviadhahami]

Hi folks :) I'm a new maintainer here, trying to help out sort all the needs;

Is this issue still a thing that requires work? (I'm unable to answer myself as I'm no longer working with a vault) I'd appreciate any input and help :)

[rbcaixeta]

Yes. This still doesn't work to write kv2 secrets. Can only read if you include /data

[rbcaixeta]

BTW, all was needed was this PR from 2 years ago, to fix this... https://github.com/nodevault/node-vault/pull/156

[aviadhahami]

PR looks good, I'm waiting for @kr1sp1n to give me CI permissions so I can allow changes in sorry for slow response :) we'll get it in soon (*hopefully )

[owenfarrell]

This is from so long ago, I might need to spend some time refreshing my memory. But I don't think #156 will totally resolve this issue.

It's a step in the right direction, but doesn't solve the issue completely.

Or so I thought when I opened it.

[aviadhahami]

@owenfarrell I agree it's been a long time, I've been trying to get into the repo so I can help out, but that took (and takes) its time ¯_(ツ)_/¯

Nonetheless, I'd appreciate your input on whether this fixes the issue or not (when u can :) )

[rhefner]

Leaving this in case anybody else is in the same predicament as I was:

We're running an old old version of Vault (1.0.0 -- yikes!) and I was able to write V2 K/V with this library, but I had to wrap whatever my data was with { data: { ... } } and also include 'data' in the path /helloworld/hello.

Instead of this which didn't work:

vault.write(`helloworld/hello`, {
  "hello": "world"
})

This worked:

vault.write(`helloworld/data/hello`, {
  "data": {
    "hello": "world"
  }
})

It also didn't require the PUT => POST change for write, but that of course could be required in later versions of Vault.

[owenfarrell]

I took a similar approach, but tried to make it more generic.

@aviadhahami - #156 is one part of the solution. To @rhefner's point, the 2nd part of the solution requires someone (either this library or a consumer) to modify (1) the URL associated with operations to inject a data or metadata path segment after the mount point and (2) read and write payloads to wrap/unwrap attributes in a data attribute.

And I'm not sure the right way to do that given the templatized nature of this implementation.

You can find my approach here):

const client: nv.client = ...;
const dataRegex = RegExp(`(\\/?${mountPointName}(?!\\/data))\\/?`);
const originalWriteFunction = client.write;
client.write = function(path, data, requestOptions): Promise<any> {
    return originalWriteFunction(path.replace(dataRegex, '$1/data/'), { data: data }, requestOptions);
};

[aviadhahami]

@owenfarrell will look into it @kr1sp1n - we still need to automate deployments here :)