How to get HashiCorp Vault policy right?

[Ashit Acharya]

Here is the situation: I created an user 'vault write auth/userpass/users/'username' password='password' policies=default' with default policy and added path "secret/db_pass/*" { capabilities = ["create","read","delete","update","list"] } in the default policy. But when I am trying to access secret/ I am getting an error 'You don't have access to secret/, though I have added permission in the policy file. Am I doing something wrong? Could some gentle soul please help? Let me know if any other information is required.

[Jeff Mitchell]

Hi there,

Vault policy matching is longest prefix so secret/db_pass/* doesn't match secret/. It also wouldn't match secret/db_pass. It would however match secret/db_pass/Foo.

Best,

Jeff

On Sat, Feb 9, 2019, 11:41 Ashit Acharya <ashita...@gmail.com> wrote:

Here is the situation: I created an user 'vault write auth/userpass/users/'username' password='password' policies=default' with default policy and added path "secret/db_pass/*" { capabilities = ["create","read","delete","update","list"] } in the default policy. But when I am trying to access secret/ I am getting an error 'You don't have access to secret/, though I have added permission in the policy file. Am I doing something wrong? Could some gentle soul please help? Let me know if any other information is required.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/ca531efb-1816-4638-a5bf-1ff677d8d41c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ashit Acharya]

Hello Jeff, 

Thanks for replying. Hope you doing well! I am pretty new to Vault. Could you please let me know how can I proceed to allow access to any user under secret/<some_name> ?

Thanks,

Ashit Acharya

[Ashit Acharya]

Hello Jeff,

Seems structure of policy has been changed. This is how I am achieving it now in V2 version:

path "secret/*"

     { capabilities = ["list"] } 

path "secret/data/db_pass" 

     { capabilities = ["create", "read", "delete", "update", "list"] }

Thanks,

Ashit Acharya

[Nathan Basanese]

To help other people who might come across this, if you are using Vault's Key/Value store, its has 2 different versions.

And each version of the Key/Value store needs a small change to the Vault Policies that allow access to it.

Note the difference here:

KV1 Create Secret: https://www.vaultproject.io/api/secret/kv/kv-v1.html#create-update-secret

Method	Path	Produces
POST	/secret/:path	204 (empty body)
PUT	/secret/:path	204 (empty body)

KV2 Create Secret: https://www.vaultproject.io/api/secret/kv/kv-v2.html#create-update-secret (has a data/ after the name of the secret engine)

Method	Path	Produces
POST	/secret/data/:path	200 application/json

It's usually better to use version 2, if you can, because it has a safer way do write-only RBAC, allows reviewing metadata without allowing reading a secret, and allows a bit more convenient auditing.

[François Prud'homme]

Hello,

I may be wrong, but if you want maximum security, i think "list" capabilitie must be set on metadata only :

path "secret/metadata/*" { capabilities = ["list"] }

And in my case, i have done something like this :

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

path "secret/metadata/db_pass" { capabilities = ["list"] }

path "secret/data/db_pass"  { capabilities = ["create", "read", "delete", "update", "list"] }

Putting some wildcard on the root of a kv store can be dangerous imho. I'm only put it on the last folder of a project in my case.