Cubbyhole but with a twist

Vault
,
1

Is there a way to use cubbyhole or something similar where users can only see their own secrets that they’ve added but an admin would be able to see all the secrets? doesn’t have to be token based or anything.

2

I know I can just attach policies to users in a scenario where the users don’t exceed say 5, but how about 100+ users ?

3

Policy Templates might be of use for you:

You can have a single policy that leverages a variable that is specific to the user.

The built-in “default” policy has an example of this.

#-- SNIP --
# 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"]
}
#-- SNIP --

It’s good to have a solid understanding of Identity Secrets when you start down the templated policies path.

1 Like
4

but it just doesn’t seem convenient when it’s for 100+ users

5

To clarify, It would be a single policy that you would apply to all your users (either via Token policy, Identity Group policy assignment, or even updating the default policy). Not a policy per user.

You would not need to customize the policy per user, the templating would effectively take care of that for you.

Using a generic example your policy could be something like:

path "secrets/{{identity.entity.name}}/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

You could then assign this simple policy to every user you manage and they’d be able to work with secrets in the secrets KVv1 mount and within a subfolder that is their Vault login name.

The “admin” policy, if it’s not root, could look like the following to give access to enumerate and view the contents of users’ secrets:

path "secrets/*" {
  capabilities = ["read", "list"]
}

Hopefully this helps!

4 Likes
6

Oh okay, that seems like a great workaround!
Thank you! :grinning_face_with_smiling_eyes:

7

So apparently identity based policies don’t work with ldap?

Or am I missing something here?

8

The issue notes weren’t 100% clear but it didn’t look like the users_metadata policy was assigned to anything after it was created.

The existence of the policy doesn’t do anything if that policy is not assigned to anything.

I’ve tested out templated policies with OIDC and JWT based logins and they worked fine (I don’t currently have an LDAP auth use case, so I haven’t explicitly tested that). I don’t see why it wouldn’t work with LDAP as long as all the pieces are in place.