Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Listing only the user folder from a KV v2 engine #8367

Open
Radecxter opened this issue Feb 17, 2020 · 4 comments
Open

Listing only the user folder from a KV v2 engine #8367

Radecxter opened this issue Feb 17, 2020 · 4 comments

Comments

@Radecxter
Copy link

Radecxter commented Feb 17, 2020

Greetings,

I'm facing difficulties to only list an user folder from a KV with all the users. Please, let me describe the scenario better.

I'm working on a Vault LDAP environment, we have LDAP as the only authentication method from Vault. Recently we had a demand for personal secrets storage inside vault. As we only work with LDAP, the cubbyhole was useless, it expires the key/values with the token and we needed something permanent assigned to the LDAP user.

As a workaround, I created a KV v2 engine called Users/ that contains every user from LDAP server and assigned a policy related to the entity alias name from the LDAP created token, allowing users to only see, edit and delete inside their own path:

#Allow user to list users path
path "Users/metadata" {
capabilities = ["list"]
}
#Allow user to Edit its own path
path "Users/data/{{identity.entity.aliases.auth_ldap_0b16465b.name}}/" {
capabilities = ["create", "read", "update", "delete"]
}
path "Users/metadata/{{identity.entity.aliases.auth_ldap_0b16465b.name}}/
" {
capabilities = ["list", "delete"]
}

This way, every user can see every other user folder in Users/ kv, but don't have permission to see inside it.

It worked fine and as expected... The issue is the amount of users listed, it became difficult to locate one specific user folder inside hundreds...

I'm facing difficulties to set a policy that only allows an user to list its own folder, something like this policy:

path "Users/metadata/{{identity.entity.aliases.auth_ldap_0b16465b.name}}" {
capabilities = ["list"]
}

Unfortunately the above policy don't work. I'm seeking something to limit the Users/ listing to only the specific user folder.

Exemplifying, inside Users/ we have:
Bob/ Joe/ Will/

When Bob log into Vault with the token from LDAP and list the Users/, he can see Bob/, Joe/ and Will/ folders, but can only read and edit inside Bob/.

I need a way to when Bob list the Users/ he would only see:
Bob/

Is this possible? With few users it doesn't is an issue at all, but with hundreds...

I've tried so many different policies to set this expected behavior, but without success... I hope you could help me some way...

Thank you so much in advance!

@draggeta
Copy link

I have exactly the same question.

@tyrannosaurus-becks
Copy link
Contributor

Hi! Thanks for posting this question.

I'm curious - it sounds like there's a folder that has lots of user names in it, and you have tried using list on it, but there are so many names that it floods the results. Have you instead tried only granting read on that user's folder? It sounds like they only have 1 folder, rather than more, so perhaps they don't need list?

@tyrannosaurus-becks
Copy link
Contributor

Also, my other question is, I'm not sure how metadata and data play into this. Can you give a more concrete example of your directory structure? Here's how I'm sort of thinking of it now but I know this is not correct:

.
└── users
    ├── alice
    └── bob

@rchench
Copy link

rchench commented Jun 9, 2022

you probably wanna remove this policy and limit the user can only create/update/list secrets under their own path.

path "Users/metadata" {
  capabilities = ["list"]
}

so to expect followings

$ vault kv list Users/
Error listing Users: Error making API request.

URL: GET xxxxxxxx
Code: 403. Errors:

* 1 error occurred:
	* permission denied

$ vault kv list Users/username
No value found at kv/username

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants