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:
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 | HashiCorp Developer
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
path “auth/token/lookup-self” {
capabilities = [“read”]
}
path “auth/token/renew-self” {
capabilities = [“update”]
}
path “auth/token/revoke-self” {
capabilities = [“update”]
}
path “sys/capabilities-self” {
capabilities = [“update”]
}
path “identity/entity/id/{{identity.entity.id}}” {
capabilities = [“read”]
}
path “identity/entity/name/{{identity.entity.name}}” {
capabilities = [“read”]
}
path “sys/internal/ui/resultant-acl” {
capabilities = [“read”]
}
path “sys/renew” {
capabilities = [“update”]
}
path “sys/leases/renew” {
capabilities = [“update”]
}
path “sys/leases/lookup” {
capabilities = [“update”]
}
path “cubbyhole/*” {
capabilities = [“create”, “read”, “update”, “delete”, “list”]
}
path “sys/wrapping/wrap” {
capabilities = [“update”]
}
path “sys/wrapping/lookup” {
capabilities = [“update”]
}
path “sys/wrapping/unwrap” {
capabilities = [“update”]
}
path “sys/tools/hash” {
capabilities = [“update”]
}
path “sys/tools/hash/*” {
capabilities = [“update”]
}
path “sys/control-group/request” {
capabilities = [“update”]
}
path “identity/oidc/provider/+/authorize” {
capabilities = [“read”, “update”]
}
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” ]
}