This assumes the following has already been done.

• Hashicorp Vault has been installed
• Hashicorp Vault has been initialized
• Hashicorp Vault has been unsealed

Let's say the secrets engine has been enabled with -path=secret/

~]# vault secrets enable -path=secret/ kv
Success! Enabled the kv secrets engine at: secret/

And let's say approle has been enabled and there is a role named "my-role" and contains a policy named "my-policy".

~]$ vault read auth/approle/role/my-role
Key                        Value
---                        -----
policies                   [my-policy]

In this example, since the secrets engine has been enabled with -path=secret/ the policy path will need to begin with secret/

Let's say "my-policy" permits the following capabilities to "secret/my_path/*".

~]$ vault policy read my-policy
path "secret/my_path/*" {
  capabilities = ["create", "delete", "list", "patch", "read", "update"]
}

You will need to include the X-Vault-Token header with a client token to connect to the Hashicorp Vault which is typically done by submitting a POST request to the /v1/auth/approle/login endpoint.

Let's say you created a secret named secret/demo using the vault kv put command and that you have the secret read permission. In this example, the keys and values of the "demo" secret will be fetched.

curl 
--request GET
--header "X-Vault-Token: s.gYGVHcHMiGsCZdKAJzWq1Yj1"
--url http://<hostname or IP address>:<port>/v1/secret/demo

Something like this should be returned.

{
  "request_id": "3dfe6f78-88ef-7b56-7727-12fb14fee302",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 2764800,
  "data": {
    "foo": "bar"
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}