// , Vault Policies

[Nathan Basanese]

  // , Here's how to make a policy using a * catch-all character: 

path "secret/data/website/database/*" {

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

}

But, suppose I have multiple websites, but I want to give a DBA access to the database secrets for them: 

path "secret/data/website1/database/*" {

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

}

path "secret/data/website2/database/*" {

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

}

Could I also give that DBA access to all paths with database in them, by the following? 

path "secret/data/*/database/*" {

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

}

It looks like that's not the case, by design: https://groups.google.com/forum/#!searchin/vault-tool/policy$20radix$20tree%7Csort:date

A notable side effect of this, though, was that * now gets used as a literal if another character comes after it: 

acl $vault token create -policy=test_radix_policy

Key                  Value

---                  -----

token                f86fa0d2-6178-3464-5f27-10614197f4c1

token_accessor       5eee8133-94fe-82b3-226a-867d2378243d

token_duration       768h

token_renewable      true

token_policies       ["default" "test_radix_policy"]

identity_policies    []

policies             ["default" "test_radix_policy"]

acl $ curl --request POST --header "X-Vault-Token: f86fa0d2-6178-3464-5f27-10614197f4c1" --data '{"passphrasey": "y"}' "${VAULT_ADDR}/v1/secret/vdev/*/database/test"

acl $ curl --request GET --header "X-Vault-Token: f86fa0d2-6178-3464-5f27-10614197f4c1" --data '{"passphrasey": "y"}' "${VAULT_ADDR}/v1/secret/vdev/*/database/test"

{"request_id":"6d595edc-e1e5-32c6-4d94-b7781fdf513f","lease_id":"","renewable":false,"lease_duration":2764800,"data":{"passphrasey":"y"},"wrap_info":null,"warnings":null,"auth":null}

acl $

I'm curious how I might accomplish something like this with Vault templates. 

I guess I could do something like this, and convert this: 

path "secret/data/website1/database/*" {

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

}

path "secret/data/website2/database/*" {

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

}

to the following: 

path "secret/data/identity.groups.names.<<group id>>.metadata.<<metadata key>>/database/*" {

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

}

...and ensure that the DBAs for all the websites were members of that group. 

However, I wonder if anyone else has come across this, or has a critique for this approach? 

What thoughts do the rest of you have on how to combine a product-oriented naming convention (website1 can't access website2's secrets) with access for functional groups (all the DBAs can access the .../database/* secrets)? 

[Jeff Mitchell]

Hi,

We don't currently have any plans to add wildcard/regex functionality
within paths, with one exception: we're exploring the ability to add
bash-style alternates, e.g.:

path "secret/data/{website1,website2}/*"

Best,
Jeff

> --
> 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/09743910-973a-4fa4-a3bb-966eb1d9f011%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.