#vault (2022-02)
Discussions related to Hashicorp Vault
2022-02-17
2022-02-23
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!
Will firstly say this may be better for the vault support forums (As there are some good vault experts lurking there, promise).
As for the KV path, a folder is just a path segment and not a secret. So no, you cannot create just an empty folder unless there is a secret in it.
Thanks! Which Vault support forums do you mean? The Hashicorp website discussion forum?
That being all said, I don’t think you need to preset any paths. That metadata, (identity.entity.aliases.auth_okta_XYZ123.name) will be evaluated at runtime and granted access to the path you have defined per your ACL.
If that is not working then ensure that the default /user/ path itself is accessible as well
(assuming you are having Okta authed accounts using the vault ui to hit secret stores and such)
Yeah, the support forum directly in hashicorp’s site. https://discuss.hashicorp.com/c/vault/30
Vault use cases, questions, and best practices discussions.
Thanks.
It does not seem to have a ton of activity but you are bound to get at least one opinionated answer to this kind of question there
The presetting was not something that has to be done, but something that might be helpful to new users who don’t have secrets and aren’t sure how to set up a standard pathing structure underneath their node.
Without it, their first step would be to create [email protected] and then secrets or folders with secrets in that.
and that sort of blows
i did hit the Vault forum, but you don’t always get a reply to more obscure questions there. This one summoned a couple of replies after I posted here.
I’ve setup some vault modules to drop blank secrets into defined paths to flesh out the UI experience before.
But I do agree KV is a pain to deal with
ah ok
that’s exactly what I wondering
I had that impulse — to drop blanks
if you’ve done that too, then that’s the feedback I was looking for
thank you
and you’re right–this is mainly a UI concern
or maybe I should say, more of a concern to users who are UI-bound
The UI is getting better at handling things but it certainly is not Vault’s selling point… heh