adobe / cryptr

Cryptr: a GUI for Hashicorp's Vault

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Enhancement] List all discoverable secrets

johnnybubonic opened this issue · comments

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.

I've had a support request open with Hashicorp for some time. Glad to see they finally added an endpoint to discover this. Feel free to provide a PR to add this improvement, but it may be some time before I can prioritize this addition.

Quick update, docs are here for the endpoint. I could have sworn it wasn't documented two days ago!

This issue is partially resolved as part of cb6d349 which will be released in v0.6.0. Cryptr now attempts to list secrets when a wildcard policy is detected at the root of a secret mount (/*).