Fix panic with Vault KV 2 secrets #186
Conversation
There was a problem hiding this comment.
From the context here this looks good to me. Caveat: I'm not super familiar with the code in envconsul nor with the Vault API you are working with so I'm mostly trusting the assumptions about those here.
I'm also assuming that this was tested against a real Vault instance to validate the API actually behaves in the way it's assumed to in the comments here.
👍 on great comments to explain what's going on!
@kyhavlov do you mind also giving it a look over as you have more context on envconsul and might spot something I didn't?
| &dependency.Secret{ | ||
| Data: map[string]interface{}{ | ||
| "metadata": map[string]interface{}{ | ||
| "destroyed": bool(false), |
There was a problem hiding this comment.
Should we be checking this field during the parsing above? I couldn't find a description in the vault docs of whether the secret would still be populated when this field is true.
There was a problem hiding this comment.
If the secret is deleted or destroyed, it wont be returned. If it's delete, you will get a response with metadata but data will be nil:
[vault][master](4)$ curl -s --header "X-Vault-Token: $VAULT_TOKEN" http://127.0.0.1:8200/v1/kv/data/something
{
"request_id": "6e926af4-37a9-2e17-679f-e9d7c7553485",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"data": null,
"metadata": {
"created_time": "2018-11-14T22:39:13.348641Z",
"deletion_time": "2018-11-14T22:43:55.199587Z",
"destroyed": false,
"version": 2
}
},
"wrap_info": null,
"warnings": null,
"auth": null
}In this case, we enter the default: case and no secret is populated (https://github.com/hashicorp/envconsul/pull/186/files#diff-a0afb4d13dc79c28cad59d370ba902caR451)
Support Vault KV2 Secrets by checking the data returned and parsing the updated KV2 format
Fixes #175