Some policy concept page clarifications

This commit is contained in:
Jeff Mitchell 2016-07-08 05:05:46 +00:00
parent 98c13d74d6
commit cf42b28487

View file

@ -125,41 +125,10 @@ For tokens, they are associated at creation time with `vault token-create`
and the `-policy` flags. Child tokens can be associated with a subset of and the `-policy` flags. Child tokens can be associated with a subset of
a parent's policies. Root users can assign any policies. a parent's policies. Root users can assign any policies.
There is no way to modify the policies associated with an active There is no way to modify the policies associated with a token once the token
identity. The identity must be revoked and reauthenticated to receive has been issued. The token must be revoked and a new one acquired to receive a
the new policy list. new set of policies.
If an _existing_ policy is modified, the modifications propagate
to all associated users instantly. The above paragraph is more specifically
stating that you can't add new or remove policies associated with an
active identity.
## Changes from 0.1
In Vault versions prior to 0.2, the ACL policy language had a slightly
different specification and semantics. The current specification requires
that glob behavior explicitly be specified by adding the `*` character to
the end of a path. Previously, all paths were glob based matches and no
exact match could be specified.
The other change is that deny had the lowest precedence. This meant if there
were two policies being merged (e.g. "ops" and "prod") and they had a conflicting
policy like:
```
path "sys/seal" {
policy = "deny"
}
path "sys/seal" {
policy = "read"
}
```
The merge would previously give the "read" higher precedence. The current
version of Vault prioritizes the explicit deny, so that the "deny" would
take precedence.
To make all Vault 0.1 policies compatible with Vault 0.2+, the explicit
glob character must be added to all the path prefixes.
However, the _contents_ of policies are parsed in real-time at every token use.
As a result, if a policy is modified, the modified rules will be in force the
next time a token with that policy attached is used to make a call to Vault.