The reason you’re getting back deny is that the path you’re hitting is cubbyhole, but the path the policy specifies is cubbyhole/*. But there’s no real point in trying to access “cubbyhole” by itself, so I think the policy as written is fine, it’s the capabilities call that’s wrong-headed. You would need to run vault token capabilities cubbyhole/ to see the effect of the given policy.
The policy is unnecessary though, because everyone gets the default policy by default, which includes:
# Allow a token to manage its own cubbyhole
path "cubbyhole/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
As far as I know the only reason you’d setup a cubbyhole policy is if you wanted to restrict access to it using the deny capability.
When I log in to the Vault using with my ldap id this is what I get
$ vault login -method=ldap username=jmalik
Password (will be hidden):
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run “vault login”
again. Future Vault requests will automatically use this token.
Where as I did create a few secrets using root token via GUI, shown below;
Hi @JawadKM - the cubbyhole backend only shows secrets that were created with the current token. So secrets created with the root token won’t be visible to anyone else (and vice versa).
The cubbyhole secrets engine is used to store arbitrary secrets within the configured physical storage for Vault namespaced to a token. In cubbyhole , paths are scoped per token. No token can access another token’s cubbyhole.
@sl1pm4t thanks for your quick reply I totally understand what you are trying to say and agree with you, but my problem is I do not see any “secret/” path when I log into my Vault all is see is as below. It is true for both when I log in with Root Token or with my ldap user id.
$ vault secrets list
Path Type Accessor Description
cubbyhole/ cubbyhole cubbyhole_81b9edca per-token private secret storage
identity/ identity identity_afbdc178 identity store
sys/ system system_4fdcb57e system endpoints used for control, policy and debugging
@ncabatoff thanks for you assistance and sorry for bothering you again and again but now I am in another road block. When use CLI to login and view the secret I can, but when I login to GUI using my ldap creds I cannot. Screenshots are as below;
$ vault login -method=ldap username=jmalik
Password (will be hidden):
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run “vault login”
again. Future Vault requests will automatically use this token.
Key Value
token s.G****************************
token_accessor B5************************
token_duration 768h
token_renewable true
token_policies [“amops” “default”]
identity_policies [“amops”]
policies [“amops” “default”]
token_meta_username jmalik
[fruser@server1 vault]$ vault kv get secret/OpenAM
=== Data ===
Key Value
The KV backends (v1, v2, cubbyhole) are all folder-like in that you can nest paths. Currently in the UI, you need to have access from the root of the mount all the way to the path you want to read. Currently if you’ve got a v1 KV engine at secret/, you’ll need to add
path “secret*” {
capabilities = [“list”]
}
to the policy you currently have. If it’s a v2 KV mount, then the paths are prefixed and the policy will look a little different:
The analogy of vault being folder-like applies alright to V1 KV. For V2 the documentations is not as comprehensible. Is there a blog post about this? The Learn site and the docs do not cover V2 very well.
