Inconsistent need for including /data in paths

Vault
1

Hi there,

Version: Vault v1.12.2, built 2022-11-23T12:53:46Z

Thanks first for providing Vault!

I’ve been somewhat confused by the seemingly inconsistent need for a /data sub-path when managing v1 secrets, particularly when assigning roles to their paths. For example:

export VAULT_ADDR='http://127.0.0.1:8200'

// Writes to /v1/secret/data/default/secrets.some-secret 
// with `/data` being inserted.
vault kv put secret/default/secrets.some-secret value=some-secret-value

vault auth enable approle

// When writing a policy I must now include the `/data`.
vault policy write my-example-policy -<<EOF
path "secret/data/default/secrets.some-secret" {
  capabilities = [ "read" ]
}
EOF

Should the vault kv put also require the /data? In fact, I think it did in earlier versions…

Thanks for any enlightenment.

Cheers,
-C

2

To which v1 are you referring to?

The /v1/ that is part of the base URL of the Vault API can be ignored - it might as well say /api/ really - the Vault API as a whole isn’t really versioned at all.

The /data/ sub-path is actually specific to the KV secrets engine, which within the one secrets engine implementation, hosts two almost completely different implementations.

KV v1 is very simple indeed. No versioning. No /data/ sub-path. No encryption of stored paths, even. It’s pretty much a direct proxy on to Vault’s underlying storage layer.

KV v2 is where many additional features are added, and amongst them, the requirement for sub-paths between the secret engine root, and the stored paths, to select amongst those features.

The purpose of the vault kv ... family of CLI commands is to abstract away some of the
more basic differences between KV v1 and v2, and to host dedicated support for KV v2 features.

A simple rule of thumb: You do not write the /data/ yourself when dealing with tooling that is explicitly built to interact with a KV v2. You do write the /data/ yourself when dealing with tooling that is built for the general Vault APIs and conventions, not any one specific secrets engine.

3

To which v1 are you referring to?

The v1 kv.

A simple rule of thumb: You do not write the /data/ yourself when dealing with tooling that is explicitly built to interact with a KV v2. You do write the /data/ yourself when dealing with tooling that is built for the general Vault APIs and conventions, not any one specific secrets engine.

Ok. Confusing, but thanks!