-
Notifications
You must be signed in to change notification settings - Fork 34
[Enhancement] List all discoverable secrets #56
Description
The problem
So in your README, you say:
NOTE: This policy addition is critical to discovering available secrets. Without this, there is no programatic way for Cryptr to know what secrets it can query to show the user. (Also, for that matter, there is no way for a human using the CLI to discover secrets, except for blindly attempting to list potential folders). As such, it is highly recommended to do this for all policies. All policies without this ability must necessarily be ignored by Cryptr.
(emphasis added)
Turns out this is false. If you hit https://<YOUR_VAULT_URI/v1/sys/internal/ui/mounts as a normal API endpoint, you get a list of all the mounted secrets engines that your current accessor has access to. (This is actually ...mostly exactly how the web UI does it internally.) From there, as long as you have read/list access inside that mount (depending on the engine) then you can enumerate paths/secrets and key names.
Here it is from a vault server -dev:
{
"request_id": "c0396842-2e5c-6da3-742c-0aab805b539f",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"auth": {
"token/": {
"accessor": "auth_token_f28431af",
"config": {
"default_lease_ttl": 0,
"force_no_cache": false,
"max_lease_ttl": 0,
"token_type": "default-service"
},
"description": "token based credentials",
"external_entropy_access": false,
"local": false,
"options": null,
"seal_wrap": false,
"type": "token",
"uuid": "92e41154-64cc-4ae9-7a85-4fbe03113eff"
}
},
"secret": {
"cubbyhole/": {
"accessor": "cubbyhole_7b6fb8f7",
"config": {
"default_lease_ttl": 0,
"force_no_cache": false,
"max_lease_ttl": 0
},
"description": "per-token private secret storage",
"external_entropy_access": false,
"local": true,
"options": null,
"seal_wrap": false,
"type": "cubbyhole",
"uuid": "7c232094-ed29-360e-0d61-68371f45db6c"
},
"identity/": {
"accessor": "identity_b6cf69d0",
"config": {
"default_lease_ttl": 0,
"force_no_cache": false,
"max_lease_ttl": 0
},
"description": "identity store",
"external_entropy_access": false,
"local": false,
"options": null,
"seal_wrap": false,
"type": "identity",
"uuid": "824ff726-13d8-c838-e49c-a65755a3ac27"
},
"secret/": {
"accessor": "kv_4cb63ca3",
"config": {
"default_lease_ttl": 0,
"force_no_cache": false,
"max_lease_ttl": 0
},
"description": "key/value secret storage",
"external_entropy_access": false,
"local": false,
"options": {
"version": "2"
},
"seal_wrap": false,
"type": "kv",
"uuid": "343bd975-37e5-011e-7e2f-b17c727c1b03"
},
"sys/": {
"accessor": "system_ac495bc9",
"config": {
"default_lease_ttl": 0,
"force_no_cache": false,
"max_lease_ttl": 0,
"passthrough_request_headers": [
"Accept"
]
},
"description": "system endpoints used for control, policy and debugging",
"external_entropy_access": false,
"local": false,
"options": null,
"seal_wrap": false,
"type": "system",
"uuid": "bc5c987a-48e3-549f-eb2d-4aeb85cbf5d4"
}
}
},
"wrap_info": null,
"warnings": null,
"auth": null
}As shown, currently mounted engines are at .data.secrets.
If you want example policies to demo this and add it as a feature, let me know but it should be relatively easy to figure them out.