Update Vault SecretStoreManager to properly handle response from Vault
Closed this issue · 1 comments
During some POC work to integrate the SecretClient
with core-data, I noticed that the Vault APIs response does not match the expected response by the vault SecretStoreManager
. The manager expects the keys to be nested under the data
key in the JSON repsonse:
go-mod-secrets/pkg/providers/vault/secret_manager.go
Lines 95 to 101 in d4cd2e3
However, using the latest Vault Docker image(1.2.2) the client was not able to obtain the keys from the response as there was another key named data
needed to inspect in order to get the secrets. Here is an example response from Vault using Postman:
{
"request_id": "68ae3221-c0da-a395-ff61-f2a1a6547566",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"data": {
"Databases.Primary.Password": "PasswordFromVault",
"Databases.Primary.Username": "usernameFromVault"
},
"metadata": {
"created_time": "2019-09-05T23:16:50.851909066Z",
"deletion_time": "",
"destroyed": false,
"version": 3
}
},
"wrap_info": null,
"warnings": null,
"auth": null
}
I updated the client to look up the data
key once more and was able to get it to work. I populated the secrets with both the HTTP API and the UI and got the same results. I think this may require a little investigation before changing. I was not able to find any documentation regarding the structure of the response. I think we should inspect the official vault client to see what it is expecting and update our client to match it. See my changes here https://github.com/AnthonyMBonafide/go-mod-secrets/commit/7a3297b41c86c47c3e59aeebe29a2a9f836d858c
Closing this issue as this issue was me populating the data incorrectly. The SecretClient
has been used with Vault and verified to be working. @difince has confirmed the functionality.