How can I list Secrets Engine through API

I’m trying to test Hashicorp Vault as a CA and was going through the API documentation. I have created a Root and an Intermediate CA under my Secrets Engine, but I can’t find an API that lists out all the secrets engine that we have available under a specific vault node.

Do we have an API call for that?

The sys/mounts API endpoint should be what you’re after:

2 Likes

Thanks that helped !!

Also is it possible to filter Secrets Engines used for creating PKI certificates

I believe you’d need to filter your results from the above endpoint by the data.${key_name}.type attribute. It should equal “pki”.

If anyone knows of a better way, I’d be interested in knowing myself.

Is it possible to provide access to a different auth method for a secret engine. I enabled AppRole, AWS & UserPass Auth method, but when I try to call the above mentioned API to fetch a list of Secret engines it says permission denied

You’ll need to give your role permission to get the contents for that endpoint.

Something like the following would need to be added to a policy and that policy associated with the role you’re using to authenticate to Vault.

path "sys/mounts" {
  capabilities = ["read"]
}

I created a role and assigned an ACL policy to it that has the following permission

path “sys/mounts” {
capabilities = [ “create”, “read”, “update”, “delete”, “sudo” ]
}

Still unable to read existing secret engine or fetch existing secret engine

Hi @sohail.galaria ,

Unfortunately, your message just doesn’t give people here enough to work with, to be able to guess what might be wrong, and help you.

If you would like to obtain help, you will need to give more precise details about what operations you are trying, and exact responses.

Exact Vault CLI commands and resulting messages, or exact HTTP requests made and responses received would be useful.

Sorry my bad.

I have created two secret engines for issuing certificates and I also created an AppRole auth method and associated it with an ACL policy that has the below mentioned permissions

path “sys/mounts” {
capabilities = [ “create”, “read”, “update”, “delete”, “sudo” ]
}

Now when I make an API call for approle login using POST v1/auth/approle/login with the role-id & secret-id, I get a Auth client token which when I use for any future calls like fetch secret engines using GET v1/sys/mounts I get a Permission denied error and also when I login from the UI and try to create a new secret engine I get the same error

To avoid complicating the conversation, let’s focus only on one issue at a time - the first one, using approle login.

As you say you get a “permission denied” error, this suggests to me you have not actually managed to link your new policy to your approle.

To check, use the GET v1/auth/token/lookup-self API. Docs: Token - Auth Methods - HTTP API | Vault by HashiCorp

Post the full output you get, except hide the “id” field because that is the secret token itself.

Here’s the output for the same

{

"request_id": "0f607305-c882-720c-5b04-1122499298ff",

"lease_id": "",

"renewable": false,

"lease_duration": 0,

"data": {

    "accessor": "Iy3SPwd3bOUlVtTqLWPdghw6",

    "creation_time": 1654109363,

    "creation_ttl": 28800,

    "display_name": "approle",

    "entity_id": "0442d495-6cf4-edfa-3a64-642d7415417b",

    "expire_time": "2022-06-01T22:49:23.20629374-04:00",

    "explicit_max_ttl": 0,

    "id": "",

    "issue_time": "2022-06-01T14:49:23.20629929-04:00",

    "meta": {

        "role_name": "testrole"

    },

    "num_uses": 0,

    "orphan": true,

    "path": "auth/approle/login",

    "policies": [

        "default",

        "test-policy"

    ],

    "renewable": true,

    "ttl": 28631,

    "type": "service"

},

"wrap_info": null,

"warnings": null,

"auth": null

}

Also posting my test-policy for reference

Allow tokens to look up their own properties

path “auth/token/lookup-self” {
capabilities = [“read”]
}

Allow tokens to renew themselves

path “auth/token/renew-self” {
capabilities = [“update”]
}

Allow tokens to revoke themselves

path “auth/token/revoke-self” {
capabilities = [“update”]
}

Allow a token to look up its own capabilities on a path

path “sys/capabilities-self” {
capabilities = [“update”]
}

Allow a token to look up its own entity by id or name

path “identity/entity/id/{{identity.entity.id}}” {
capabilities = [“read”]
}
path “identity/entity/name/{{identity.entity.name}}” {
capabilities = [“read”]
}

Allow a token to look up its resultant ACL from all policies. This is useful

for UIs. It is an internal path because the format may change at any time

based on how the internal ACL features and capabilities change.

path “sys/internal/ui/resultant-acl” {
capabilities = [“read”]
}

Allow a token to renew a lease via lease_id in the request body; old path for

old clients, new path for newer

path “sys/renew” {
capabilities = [“update”]
}
path “sys/leases/renew” {
capabilities = [“update”]
}

Allow looking up lease properties. This requires knowing the lease ID ahead

of time and does not divulge any sensitive information.

path “sys/leases/lookup” {
capabilities = [“update”]
}

Allow a token to manage its own cubbyhole

path “cubbyhole/*” {
capabilities = [“create”, “read”, “update”, “delete”, “list”]
}

Allow a token to wrap arbitrary values in a response-wrapping token

path “sys/wrapping/wrap” {
capabilities = [“update”]
}

Allow a token to look up the creation time and TTL of a given

response-wrapping token

path “sys/wrapping/lookup” {
capabilities = [“update”]
}

Allow a token to unwrap a response-wrapping token. This is a convenience to

avoid client token swapping since this is also part of the response wrapping

policy.

path “sys/wrapping/unwrap” {
capabilities = [“update”]
}

Allow general purpose tools

path “sys/tools/hash” {
capabilities = [“update”]
}
path “sys/tools/hash/*” {
capabilities = [“update”]
}

Allow checking the status of a Control Group request if the user has the

accessor

path “sys/control-group/request” {
capabilities = [“update”]
}

Allow a token to make requests to the Authorization Endpoint for OIDC providers.

path “identity/oidc/provider/+/authorize” {
capabilities = [“read”, “update”]
}

Allow a token to manage its own secret engines

path “sys/mounts/*”
{
capabilities = [“create”, “read”, “update”, “delete”, “list”, “sudo”]
}

When you paste code or config into Discourse, you really need to surround it with ``` markers. Please look at the crazy formatting which has been applied to your previous post, because it has been interpreted as Markdown syntax.

This is your problem. You’ve added a /* to the end of the path, so it no longer matches a "read" of sys/mounts.

Yep, didn’t realize that. Thanks for going through that crazy stuff and helping out though. It looks like the sys/mounts/* was the problem

Just to clarify though that when I use the same client token received from the API call to login to UI it still gives me the same access denied error

Ok I think I was able to solve it myself by adding another path to my policy for managing PKI as below

path “pki*” {
capabilities = [ “create”, “read”, “update”, “delete”, “list”, “sudo” ]
}