I noticed that
kv2 could not use
denied_ parameters, and
required_ parameters limit.
kv secrets itself limit the matching of keys and values that can be passed in?
keyName = ["value*end"]
We can only write
secret/keypath, and write
I’m not entirely sure what you’re after, can you provide some example commands and then describe the intended result?
In absence of that, I’ll attempt to address your question:
If you’re looking to use wildcards (e.g.
*) then you’ll need to understand they don’t really exist in Vault and you’ll have to work around the limitations. The
*, or “glob” character, can only be used at the end of a string; it cannot be used to match arbitrary text at the beginning or middle of a string. If you’re looking to enforce a particular format within a key’s value you’d only be able to enforce a prefix.
As you noted the KV v2 secret engine doesn’t support the fine-grained policies, however KV v1 does. If you want to emulate the behavior in KV v2 then, I believe, you’d need to use Sentinel policies (Enterprise feature) to define what is and isn’t allowed in your KV v2 secrets. Sentinel policies are 100% custom and should be able to accomodate any use case you have. However, there is an open feature request to add this functionality - I’d suggest giving it a “Thumbs Up” if this is something you’d like to see added to Vault.
Thank you. Yes, I hope to limit the storage of keys or values in kv2 secrets, and even process them through regular expressions, so that there is no need to do another layer of encapsulation in some scenarios. Encapsulation will waste the high availability services provided by vault clusters.
This is exactly what is needed.