Presetting Empty "Folders" for Individual Users

Vault
1

Vault: v1.9.3 (OSS)
O.S.: Centos7
HA = Enabled
storage_type = Consul v1.11.2

Hi,

I’m deploying Vault with Okta as the auth method. I intend to use ACL templating in policies to give each user control over a personal and persistent (i.e., non-cubbyhole) area of the KV version 2 secrets engine. To wit:

path "kv/data/user/{{identity.entity.aliases.auth_okta_XYZ123.name}}/*"
{
    capabilities = [ "create", "update", "read", "delete", "list" ]
}

*etc. related policies*

The problem is that the part of the path that is specific to the user:

{{identity.entity.aliases.auth_okta_XYZ123.name}}/*

is not created before the user logs in and is not automatically created after authentication. So, unless I’m totally (and entirely possibly!) misunderstanding how this is supposed to work, I’m left with an awkward workflow that boils down to presetting the paths for hundreds of users (without foreknowledge of whether they even intend to login), or asking them to create directories matching their login ids when they login for the first time.

Additional confusion is wrought by the fact that it doesn’t seem possible to create an empty k/v entry that acts as a “folder”. Is that true?

What is the right way to accomplish what I’m trying to do?

Thanks!

2

Hi @john.pagano,

Your observations here are correct. In order to have the folders appear something needs to exist in them. It’s not quite like a file system where folders are an object, but rather the folders only exist when something exists in them (i.e. they’re used as a visual organizational component, and for policy application, as opposed to an actual storage container).

So you are correct - either you need to drop a dummy/temporary secret in each user’s folder or you provide them with instructions for creating their first secret.

As with many things, there’s no “right way” to do things, but rather what makes the most sense for your environment.

3

Hi, @jeffsanicola,

Thanks again for the useful info.

I’m disappointed to learn this, since it seems to work against adoption by individual users–especially non-technical ones–for managing personal and non-patterned secrets. But to your point, with me being new to the solution, I could be missing some other way of covering that sort of use case.

UPDATE:

But with that said, now I’m struggling to understand the use case for sending users to ACL-templated paths at all!

4

@john.pagano The ACL-templated paths are there simply to allow the introduction of user-specific auth methods, secret engines, and namespaces. These policies based on a user allow you to have very fine grained access with the no privilege principle.

Whatever else you want to do is up to you. Vault will never just define anything for you that you didn’t explicitly define. So this means that any kind of secret engine, authentication method or namespace you want to setup is completely up to you and won’t automatically be done by Vault.
The policies just make it easier for you to have such access control “template” without having to duplicate and write multiple lines of policy code!