luxolus/open-vault
2
0
Fork 0
Code Issues 1 Pull requests Releases Activity

docs: update "Policy Syntax" section (#10590)

Browse source 
Co-authored-by: mgritter <mgritter@hashicorp.com>
This commit is contained in:
Aleksandr Bezobchuk 2021-01-26 23:14:47 -05:00 committed by GitHub
parent 6ce93f8cbf
commit 46c3f1f7bc
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 25 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
website/content/docs/concepts/policies.mdx
View file

@ -170,11 +170,30 @@ corresponding path and capability - even Vault's internal core configuration
endpoints live under the `"sys/"` path. Policies define access to these paths and endpoints live under the `"sys/"` path. Policies define access to these paths and
capabilities, which controls a token's access to credentials in Vault. capabilities, which controls a token's access to credentials in Vault.
~> Policy paths are matched using the **most specific path match**. This may be ~> The policy rules that Vault applies are determined by the most-specific match
an exact match or the longest-prefix match of a glob. This means if you define a available, using the priority rules described below. This may be an exact match
policy for `"secret/foo*"`, the policy would also match `"secret/foobar"`. or the longest-prefix match of a glob. If the same pattern appears in multiple
policies, we take the union of the capabilities. If different patterns appear in
the applicable policies, we take only the highest-priority match from those
policies.
!> The glob character referred to in this documentation is the asterisk (`*`). It _is not a regular expression_ and is only supported **as the last character of the path**! This means if you define a policy for `"secret/foo*"`, the policy would
also match `"secret/foobar"`. Specifically, when there are potentially multiple
matching policy paths, `P1` and `P2`, the following matching criteria is applied:
1. If the first wildcard (`+`) or glob (`*`) occurs earlier in `P1`, `P1` is lower priority
2. If `P1` ends in `*` and `P2` doesn't, `P1` is lower priority
3. If `P1` has more `+` (wildcard) segments, `P1` is lower priority
4. If `P1` is shorter, it is lower priority
5. If `P1` is smaller lexicographically, it is lower priority
For example, given the two paths, `"secret/*"` and `"secret/+/+/foo/*"`, the first
wildcard appears in the same place, both end in `*` and the latter has two wildcard
segments while the former has zero. So we end at rule (3), and give `"secret/+/+/foo/*"`
_lower_ priority.
!> The glob character referred to in this documentation is the asterisk (`*`).
It _is not a regular expression_ and is only supported **as the last character of the path**!
When providing `list` capability, it is important to note that since listing When providing `list` capability, it is important to note that since listing
always operates on a prefix, policies must operate on a prefix because Vault always operates on a prefix, policies must operate on a prefix because Vault

3
website/content/docs/internals/security.mdx
View file

@ -118,7 +118,8 @@ client), the highest access level permitted is used. For example, if the
"engineering" policy permits read/update access to the "eng/" path, and the "engineering" policy permits read/update access to the "eng/" path, and the
"ops" policy permits read access to the "ops/" path, then the user gets the "ops" policy permits read access to the "ops/" path, then the user gets the
union of those. Policy is matched using the most specific defined policy, which union of those. Policy is matched using the most specific defined policy, which
may be an exact match or the longest-prefix match glob pattern. may be an exact match or the longest-prefix match glob pattern. See
[Policy Syntax](../concepts/policies.mdx#policy-syntax) for more details.
Certain operations are only permitted by "root" users, which is a distinguished Certain operations are only permitted by "root" users, which is a distinguished
policy built into Vault. This is similar to the concept of a root user on a policy built into Vault. This is similar to the concept of a root user on a