We setup HashiCorp Vault and need to create a simple static key/value store within the KV secrets engine. Who is ultimately responsible for creating this secret or secrets in general?
Should we create a username/password for that particular user so that they can create the secret and manage it?
I am trying to wrap my head around a standard vault workflow. Also, when we create secret engines/secrets within the root account are these shared across other users or do we need to grant access?
Thank you,
Hello,
Regarding this :
We setup HashiCorp Vault and need to create a simple static key/value store within the KV secrets engine. Who is ultimately responsible for creating this secret or secrets in general?
The short answer would be anybody who has access to that path. Vault makes heavy usage of paths, the best way I find thinking about Vault’s structure is that it resembles filesystem with files and folders.
If your secret lives in secret/my-secret path, every user who possesses a policy allowing managing that path would be able to read and modify the secret (my-secret).
Regarding this :
Should we create a username/password for that particular user so that they can create the secret and manage it?
That would be preferable, you can create a policy that has limited scope to that particular secret. Here is a simple policy that defines full set of permissions to secret/my-secret path :
path "secret/my-secret"
{
capabilities = ["create", "read", "update", "delete", "list"]
}
Regarding this :
I am trying to wrap my head around a standard vault workflow. Also, when we create secret engines/secrets within the root account are these shared across other users or do we need to grant access?
The secrets are written in particular paths, accessing a secret strictly depends on the policies assigned to the user (token) that is trying to access it.
Martin
1 Like
thank you! just to confirm, the single token associated with a username/password will only be capable of completing the actions based on the policy or policies assigned to that token? I’m reading the documentation now but just want to ensure that I’m not overlooking anything. The concepts are beginning to make sense now.
Hello,
Regarding this :
just to confirm, the single token associated with a username/password will only be capable of completing the actions based on the policy or policies assigned to that token?
You are correct, the actual permissions are based on the policies attached to the token. The token itself might be created by various different auth method, for example : userpass (end user has username and password that are local to Vault) , OIDC , LDAP and so on.
The easiest way i found to think about tokens is that they resemble session cookies to some degree.
Martin
1 Like
“The easiest way i found to think about tokens is that they resemble session cookies to some degree.” makes perfect sense, thank you!