safe fails to set/get secrets when used against a Vault v0.10.0 dev server

[alvaropinot]

safe fails to set/get secrets when used against a Vault v0.10.0 dev server. The version is just 12 days old so it might not be impacting users with already running vault instances. I can confirm it works against Vault v0.9.6

Steps to reproduce

Failing scenario

Versions

• Vault v0.10.0 ('5dd7f25f5c4b541f2da62d70075b6f82771a650d')
• safe v0.7.0

Running the cmd DEBUG=on safe set secret/ssh username=system
exits 1 with the following trace:

DEBUG=on safe set secret/handshake knock=knock
Request:
GET /v1/secret/handshake HTTP/1.1
Host: 127.0.0.1:8200
X-Vault-Token: 531a49bc-ecfd-03aa-43de-62730ca9c525


----------------
Response:
HTTP/1.1 404 Not Found
Content-Length: 331
Cache-Control: no-store
Content-Type: application/json
Date: Mon, 23 Apr 2018 01:19:46 GMT

{"request_id":"bdd85613-ccbf-22c4-0af7-895edbb76525","lease_id":"","renewable":false,"lease_duration":0,"data":null,"wrap_info":null,"warnings":["Invalid path for a versioned K/V secrets engine. See the API docs for the appropriate API endpoints to use. If using the Vault CLI, use 'vault kv get' for this operation."],"auth":null}
----------------
knock: knock
Request:
POST /v1/secret/handshake HTTP/1.1
Host: 127.0.0.1:8200
X-Vault-Token: 531a49bc-ecfd-03aa-43de-62730ca9c525

{"knock":"knock"}
----------------
Response:
HTTP/1.1 404 Not Found
Content-Length: 331
Cache-Control: no-store
Content-Type: application/json
Date: Mon, 23 Apr 2018 01:19:46 GMT

{"request_id":"27fb3d10-1e10-d446-beaf-9009cb82b820","lease_id":"","renewable":false,"lease_duration":0,"data":null,"wrap_info":null,"warnings":["Invalid path for a versioned K/V secrets engine. See the API docs for the appropriate API endpoints to use. If using the Vault CLI, use 'vault kv put' for this operation."],"auth":null}
----------------
!! API 404 Not Found

Working scenario

Versions

• Vault v0.9.6 ('7e1fbde40afee241f81ef08700e7987d86fc7242')
• safe v0.7.0

Running the same cmd DEBUG=on safe set secret/ssh username=system
exits 0 with the following trace:

Request:
GET /v1/secret/ssh HTTP/1.1
Host: 127.0.0.1:8200
X-Vault-Token: 04ed3a9d-1733-45bb-5b39-23f9dc1464ed


----------------
Response:
HTTP/1.1 200 OK
Content-Length: 185
Cache-Control: no-store
Content-Type: application/json
Date: Mon, 23 Apr 2018 01:29:44 GMT

{"request_id":"16694037-2c2c-9bdb-deeb-11f77ed18a23","lease_id":"","renewable":false,"lease_duration":2764800,"data":{"username":"system"},"wrap_info":null,"warnings":null,"auth":null}

----------------
username: system
Request:
POST /v1/secret/ssh HTTP/1.1
Host: 127.0.0.1:8200
X-Vault-Token: 04ed3a9d-1733-45bb-5b39-23f9dc1464ed

{"username":"system"}
----------------
Response:
HTTP/1.1 204 No Content
Content-Length: 0
Cache-Control: no-store
Content-Type: application/json
Date: Mon, 23 Apr 2018 01:29:44 GMT


----------------

Hopefully I'm not exposing any secrets in those traces 😅as the dev server is already dead 😜

Looks like Vault's UI have a similar issue (hashicorp/vault#4348) and it might be due to a misalignment with any new possible API changes, it also looks like Vault may not be following semver and they might had introduced a breaking change in v0.10.0. Here the CHANGELOG in case it helps 👉https://github.com/hashicorp/vault/blob/v0.10.0/CHANGELOG.md

Please let me know if I can help any further 😄

[jhunt]

Yeah, it definitely looks like 0.10.0 is a breaking change, at least if you didn't run vault secrets enable. IIRC, the Vault team maintains that 0.x.x is not really a major version, and they exempted themselves from the rigors of semver. ¯_(ツ)_/¯

Might I recommend 0.9.x, or running vault secrets enable?

On a deeper level, this is more troubling for our future with Vault, since they seem to be advocating for versioned secrets. 0.10.x looks (on the surface) like a marked departure from previous behavior, and a dismissal of our "dumb key-value storage" model of interacting with Vault everywhere. It might be time to start looking at alternate backends for credentials storage.

[lvets]

On a deeper level, this is more troubling for our future with Vault, since they seem to be advocating for versioned secrets. 0.10.x looks (on the surface) like a marked departure from previous behavior, and a dismissal of our "dumb key-value storage" model of interacting with Vault everywhere. It might be time to start looking at alternate backends for credentials storage.

Strange question, and maybe not the correct medium to ask this, but what's so wrong about versioned secrets? I agree that not all of their reasons are sound ("This made it difficult to recover from unintentional data loss", backups anyone?), but password rotation would benefit a lot from this...

[jhunt]

Versioned secrets are great, until you aren't sure which ones are in use.

[jhunt]

To clarify my somewhat terse response: credentials rotation is a definite boon, but you don't need versioned secrets for that. I haven't read a ton into their implementation to know if its indefinite history or configurable, but either way, keeping your passwords around indefinitely can lead to confusion as to which credential is in force. As you rightly point out, backups are a better way of doing this, and we have a ticket (#133) to work on a safe-native way of doing backups that doesn't leave the backed-up credentials easily accessible without restoring the backup. I think that's the best solution because you still have your old secrets, but you can't use them easily, which prevents people form just referencing the specific version of a password and actively working against the rotation scheme.

[thomasmitchell]

0.10.0 works on v1.0.0. kv v2 is supported in v1.0.0