Hi Team ,
I am Configuring OIDC Auth method referring to Link
I am Succeffuly logged in into the Vault via Keycloak cli but I am unable to view/Create Access Methods, Secret engines etc
Error:1 error occurred: * permission denied
Not sure where i am doing wrong . Kindly help
What policies are associated with the token once you’ve successfully have logged into Vault via OIDC?
Thank you for the Response.
I am trying the manager policy created during the process as per the documentation.
Manager.hcl
path “/secret/*” {
capabilities = [“create”, “read”, “update”, “delete”, “list”]
}
That policy allows you to interact with secrets in the secret KV mount path only.
If you want to manage auth mounts and secret engine mounts then you’ll need to add some more rules to the policy.
Have a look through the following API docs for the default paths that will be helpful:
Also take a look at the relevant sections for the auth and secret types you’re interested in managing as those will have additional paths specific to those mounts that need to be considered.
I find the API docs really helpful when constructing least-privilege policies.
Thank you for Sharing the Documentation.
What if i want root level access to the OIDC user i am creating ? What policies i Should create & i am wondering i can only access relevant secrets/access only if i specify the mount path during the login ?
This policy would approximate the root policy, I wouldn’t recommend it beyond testing though:
path "*" {
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
Edit: Fixed quotes in path
Thank you @jeffsanicola it worked .But now i am unable to create any secret engines as it throws * unsupported path 
What command are you running to create the secret engine?
I am Creating the Secret Engine via Web UI & I have updated the policy
Attached is the policy i am using
admin.hcl.txt (2.0 KB)
Now I am getting different error Unauthorized access after creating Secret engine " No access to /aws path
Try adding this to your policy:
path "/sys/internal/ui/mounts" {
capabilities = ["read", "list"]
}
It’s supposed to be an unauthenticated endpoint but I added it to my admin policy a while back presumably because I was running into an access denied message when performing similar operations.
The other thing you can do is to enable an audit device and inspect the “permission denied” paths to see if they’re included in your policy. This is typically how I troubleshoot my own policies, particularly for GUI access.