Vault: Cubbyhole secret backend per user identity

[brettcave]

Feature Request:

The cubbyhole secret backend works great for storing secrets within the context of a token. However, in the case of using an authentication backend such as LDAP, an authentication token may expire and a user will re-authenticate receiving a new token. The new token does not have access to items under the old token's cubbyhole, even though the user identity that owns both tokens is the same.

A secret backend isolated in context of a user identity, regardless of token, would be useful if this use-case is widely used.

Steps to Reproduce:

1. authenticate via ldap
2. store a value in cubbyhole (and validate it is there)
3. re-authenticate via ldap (new token issued)
4. old cubbyhole item is not accessible

$ vault auth -method=ldap username=brett
Password (will be hidden): 
Successfully authenticated! You are now logged in.
token: token-a-redacted-xxx
token_policies: [redacted]
$ vault write cubbyhole/mycubby secret=thisismysecret
Success! Data written to: cubbyhole/mycubby
$ vault read cubbyhole/mycubby 
Key     Value
---     -----
secret  thisismysecret

$ vault auth -method=ldap username=brett
Password (will be hidden): 
Successfully authenticated! You are now logged in.
token: token-b-redacted-yyy
token_policies: [redacted]
$ vault read cubbyhole/mycubby 
No value found at cubbyhole/mycubby

[jefferai]

I'm closing this simply because it's on our internal roadmap but is waiting on some things to happen first. It's going to come though!

[brettcave]

Great to hear @jefferai , looking forward to it.

[overmike]

I am looking forward to it, is there any target date? Early 2018?

[jefferai]

No target date currently.

[mhglover]

Any target date for this functionality yet?

[jefferai]

Not yet. Part of this is that there is some work going into enhancing the ACL system (for 0.11) to allow some interpolation of Identity values (see #4195). When that lands, likely there won't be a need for a specific backend for per-identity secrets, because you can just set up an entire K/V mount or specific areas of any K/V mount (of either v1 or v2) with interpolated paths. That also would let you leverage group membership and metadata assigned to entities as gatekeepers. It should have all of the flexibility of what was discussed here and way more.

[hgwood]

Hello, I've published an article on this feature here. I hope it makes sense and can help some of you.

[Radecxter]

Hi guys,
Any update on this feature?

[jefferai]

See the previous two comments -- use Identity path templating with a normal KV mount.